EldoS | Feel safer!

Software components for data protection, secure storage and transfer

File attribute caching issue

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
Posted: 03/23/2009 16:47:46
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

OK, the next place I tried to call NotifyDirectoryChange is in the CbFsCloseFile callback and that didn't seem to do the trick either.
Posted: 03/24/2009 01:36:24
by Volodymyr Zinin (Team)

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".
Posted: 03/24/2009 10:07:11
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

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.
Posted: 03/24/2009 10:18:06
by Volodymyr Zinin (Team)

Sid Schipper wrote:
You say that the NotifyDirectoryChange happens asynchronously...

Only if it's called in the callback functions context. Outside the callbacks it's called synchronously.

Sid Schipper wrote:
... 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

Then something is wrong. Please specify a code snippet that contains the NotifyDirectoryChange call.
Posted: 03/24/2009 11:25:14
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

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.

[ Download ]
Posted: 03/24/2009 11:51:54
by Volodymyr Zinin (Team)

Seems the error is here:
CString strFullPath(strDriveLetter);
strFullPath += strFileName;

strFullPath must not contain a drive letter. The path must be relative to the root directory (i.e. "\dir1\dir2\...\file_name").
Posted: 03/24/2009 12:18:32
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Hmm! Does that mean that CbFs knows that it is the S: drive?
Posted: 03/24/2009 12:37:58
by Volodymyr Zinin (Team)

Yes, it does. NotifyDirectoryChange is a member of the CallbackFileSystem class and it contains information about a destination drive.
Posted: 03/24/2009 13:11:58
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

OK, Vladimir, you rock!

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.
Posted: 03/24/2009 14:15:49
by Volodymyr Zinin (Team)

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.
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.



Topic viewed 23305 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!