NotifyDirectoryChange called inside the callbacks is processed asynchronously. I.e. the call returns immediately and the function is called in the context of the CallbackFS internal thread. Please look at my first message in this topic about an additional information for the function.
So it's better to call the function outside the callbacks, after a file for which the function is called has already been modified. Also it is good idea not to change a file using another (than CallbackFS) mechanism/interface if it has already been opened for writing via CallbackFS. And vice versa, not to allow to open a file in CallbackFS if it has already been opened by someone else. Because data of the file can be damaged in a case of concurrent writing. That's why NotifyDirectoryChange in a case if a file has already been opened in CallbackFS purges all the cached file's data (and it's attributes) and markes handles for it as "bad". So owners of these handles, i.e. programs that opened the file, won't be able to use them to access to the file (any operation, except CloseHandle, with these handles will return an error).
But sure, it's up to you how to resolve such "race conditions".

OK, I think I understand what you are saying, but I am a bit puzzled by something.

You say that the NotifyDirectoryChange happens asynchronously, but in my case I never see the CbFsReadFile callback called for that file that I have truncated to 1K bytes for a read of anything but 32K bytes, no matter how long I wait for it to happen, even overnight, it never happens, until I DeleteStorage on the callback file system where that Mounting Point is defined. Once I do that and then create the storage and remount the drive, then the reads start occurring for 1K bytes, so it seems like the NotifyDirectoryChange either is not taking effect at all, or doesn't take effect until you remount the drive in CbFs.

Is that true? There are so many other things going on and all this is pretty complicated, so I may me misinterpreting the events that are occurring, but I'm pretty sure I have it right.

OK, I am attaching my complete CbFsReadFile callback. The call to NotifyDirectoryChange is at the very end of the routine.

Much of the stuff at the beginning pertains to my database system, which is called SRB, so anytime you see the prefix srb_, or Srb, or SRB, you can assume it is something that is not relevant to CbFs, although the interaction between them may be important.

I also do some mutex locking and unlocking and that is done to handle the
multi-threaded nature of my CbFs application. I am keeping track of various data structures using MFC CMap structures that are shared among various threads in my application, so that is why I need the mutexes.

As I said earlier, much of this you can ignore, but I thought it would be easier to send you the whole callback routine rather than just the part that calls NotifyDirectoryChange.

I made the change you suggested and now the NotifyDirectoryChange works as advertised.

One thing I am a bit concerned about is your explanation about the invalidation of internal file handles by the NotifyDirectoryChange function.

Suppose in my GetFileInfo callback, every time I get a request for the file information on any file that exists on my virtual disk, I call NotifyDirectoryChange, even if I am not really changing anything? Is this dangerous?

If so, do you know any way for me to determine in the GetFileInfo callback the file size that Windows is maintaining for the file handle that it is using for the ReadFile callback?

I thought about using the GetFileSizeEx Windows API, but that seemed like circular logic, in other words calling that function from within the GetFileInfo callback would probably just call the GetFileInfo callback recursively and get me into an infinite loop.

It isn't allowed from the callbacks to access files on the same virtual storage that these callbacks support, because this can cause a deadlock. Your callbacks should "know" everything about files on the supported virtual storage.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.