Monitor multiple files failures under Windows

[huyi51462]

I monitor a directory named "d:\A".
There is another folder path "d:\B" which has 1000 files, each file is about 200kb.
Copy folder B to folder A, the callback function works normally at first, but about halfway through, iocp no longer wakes up the child thread, the child thread is hangs in GetQueuedCompletionStatus(), and there is no response.
What went wrong?
Is it not possible to monitor files over a certain number or size?

[huyi51462]

When you first call ReadDirectoryChangesW, the system allocates a buffer to store change information. This buffer is associated with the directory handle until it is closed and its size does not change during its lifetime. Directory changes that occur between calls to this function are added to the buffer and then returned with the next call. If the buffer overflows, ReadDirectoryChangesW will still return true, but the entire contents of the buffer are discarded and the lpBytesReturned parameter will be zero, which indicates that your buffer was too small to hold all of the changes that occurred.

The buffer is too small for changes that need to monitor a large number of files.

[SpartanJ]

The buffer size was limited because of an old Windows bug, at least that's what it says in the code:

efsw/src/efsw/WatcherWin32.hpp

Line 62 in b60a4e6

BYTE Buffer[63 * 1024]; // do NOT make this bigger than 64K because it will fail if the folder being watched is on the network! (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx)

I can probably increase the buffer size.
I will take a look at this issue. Here are some remarks in the documentation:
https://docs.microsoft.com/en-gb/windows/win32/api/winbase/nf-winbase-readdirectorychangesw?redirectedfrom=MSDN#remarks

[huyi51462]

The buffer size was limited because of an old Windows bug, at least that's what it says in the code:
I can probably increase the buffer size.

Yes, what occupies this buffer is actually the string of the file path,so in the case of a large number of files or many long path files, 64k is too small.

[solarispika]

In the current implementation, it seems impossible to determine whether the ReadDirectoryChangesW() call has failed or not. Is it possible to provide users with information about any failures, so they can react accordingly?
Another suggestion could be to allow users to specify the buffer size or provide the buffer themselves, enabling them to tailor it to their needs. In this way, the onus is on the users to customize the buffer as necessary.

[SpartanJ]

That's a totally reasonable request. I've got to think of a good API for that and make it as a non-breaking change. If you have some minutes can you open a ticket for this specific feature request? Thanks

[SpartanJ]

This issues has been fixes thanks to the @r00tcxx contribution in this PR. :)