FileSystemWatcher InternalBufferOverflow [英] FileSystemWatcher InternalBufferOverflow

本文介绍了FileSystemWatcher InternalBufferOverflow的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当我尝试监视网络路径(DFS-分布式文件系统)上的文件夹时,出现异常System.IO.Internal.BufferOverflowException:一次要进行许多更改.当FileSystemWatcher监视不使用此文件系统的本地/网络路径时,它可以正常工作.

I am getting an exception System.IO.Internal.BufferOverflowException when I am trying to monitor a folder on network path(DFS - Distributed File System): To many changes at once . It works fine when FileSystemWatcher is monitoring local/network path that don't use this filesystem.

我能够从本地路径上的1000多个文件中获取事件,而我没有收到BufferOverflow异常,但是,当我将文件复制到DFS上的文件夹时,我什至无法从一个事件中获取事件.弄清楚这一点,我收到了一个错误事件……).

I am able to get an event from 1000 + files on local path and I am not getting BufferOverflow exception, however when I am copying file to folder that is on DFS I am not even able to get an event from one(To clarify this, I am getting an error event raised...).

我已经尝试设置:

fileSystemWatcher.InternalBufferSize = 65536;

我不确定这是否对您有帮助,但是路径如下所示:

I am not sure if this will help you but the path look like this:

\\corpnet\cloud\\Network\testFolder\myFolderToMonitor

1 我不确定为什么路径中有两个双斜杠.我可以监视没有问题的文件夹,直到 \ corpnet \ cloud 路径.尝试监视从

1 I am not sure why there are two double slashes in path. I can monitor without a problem folder till the \corpnet\cloud path. I am getting errors once I am trying to monitor any folder that is starting from

...\\Network\...

感谢您的任何提示.

谢谢

推荐答案

当然,一次更改太多,这是一个 firehose 问题.您已经将缓冲区大小增加到允许的最大值,Windows不允许更大.它分配在宝贵的"内存(内核内存池)中.

Sure, too many changes at once, this is a firehose problem. You've already increased the buffer size to the maximum allowed, Windows doesn't allow a bigger one. It is allocated in "precious" memory, the kernel memory pool.

可以是高度活跃的文件服务器,但更常见的是,这是由您的代码中的问题引起的.您从饮水器中喝水的速度不够快.至关重要的是,事件处理程序必须尽快返回,以便足够快地清空缓冲区,并且可以跟上文件服务器上的更改速度.

This could be a highly active file server, but much more commonly this is caused by a problem in your code. You don't drink from the firehose fast enough. It is imperative that your event handlers return as quickly as possible so that the buffer is emptied fast enough and can keep up with the rate of changes on the file server.

这常常很糊涂,一个典型的实现会做一些不明智的事情,例如复制文件,读取文件,循环直到文件可以打开.昂贵的东西,循环错误是一个非常常见的错误,事件触发时文件很少可用,因为任何更改文件的应用程序仍会打开它.可以将文件锁定多长时间也没有上限.显然,这总是会导致缓冲区溢出.

That's very often fumbled, a typical implementation does something unwise like copying the file, reading it, looping until the file can get opened. Expensive things, the looping bug is a very common mistake, a file is very rarely usable when the event fires because whatever app that changes the file still has it opened. There's no upper limit either on how long it can keep a lock on the file. Clearly that will always cause a buffer overflow.

因此,正确实现的FileSystemWatcher事件处理程序不会执行任何操作,而是将传递的文件路径快速放入线程安全的队列中,并且不执行其他任何操作,而这绝不应该超过一微秒.并使用另一个线程尝试再次清空该队列,以处理可能无法打开文件的可能性.

So a properly implemented FileSystemWatcher event handler does nothing but quickly put the passed file path into a thread-safe queue and does nothing else, that never ought to take more than a microsecond. And uses another thread to try to empty that queue again, dealing with the likelihood that the file can't be opened yet.

这篇关于FileSystemWatcher InternalBufferOverflow的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆