FileSystemWatcher InternalBufferOverflow

我是研究僧i 提交于 2019-12-06 11:51:24

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.

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.

I got the same issue. There is no problem watching a local folder and dropping in 5 new files. But when I watch a network folder, I get the error "Too many changes at once in directory". It's only 5 files.

You already found a fix?

I can't really adjust the code so my temporary fix is to drop the files in a temp folder and poll that folder. When there are new files, I move them separately with 500ms delay

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!