EldoS | Feel safer!

Software components for data protection, secure storage and transfer

SHCNE_UPDATEDIR in Vista

Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.
#9984
Posted: 05/12/2009 06:58:09
by Tim Hayes (Standard support level)
Joined: 06/06/2007
Posts: 36

My application uses SHChangeNotify rather than cbfs.notifydirectorychange because of locking issues with critical sections.

When the underlying database has changed, I notify Windows in an external thread. Straight afterward, the file properties in the shell window shows the correct new length of the data file, hence the directory enumeration following the call of SHChangeNotify must have correctly occurred.

However, when opening the file, CBFS is still reading the file with the original length passed into CbFsFsRead as BytesToRead. I have recently updated to the latest CBFS drivers etc, and seem to think that I did not have this issue with the older drivers, albeit under Windows XP.

Any ideas please?
#9985
Posted: 05/12/2009 07:14:31
by Tim Hayes (Standard support level)
Joined: 06/06/2007
Posts: 36

Have just tried to use DisableMetaDataCache to see if I can suppress any caching of the file size. However, when I call :

FCbFs.DisableMetaDataCache(true);

I get an exception.
#9986
Posted: 05/12/2009 07:29:30
by Volodymyr Zinin (EldoS Corp.)

Use cbfs.notifydirectorychange. It works correctly now.
BTW: There were several discussions in this forum about the function. So you can find some useful information there. For example here: http://www.eldos.com/forum/read.php?FID=13&TID=1634.
#9987
Posted: 05/12/2009 07:36:23
by Volodymyr Zinin (EldoS Corp.)

Quote
Tim Hayes wrote:
Have just tried to use DisableMetaDataCache to see if I can suppress any caching of the file size. However, when I call :

FCbFs.DisableMetaDataCache(true);

I get an exception.

Perhaps you call it when the virtual storage is not mounted yet.
#9989
Posted: 05/12/2009 08:15:46
by Tim Hayes (Standard support level)
Joined: 06/06/2007
Posts: 36

On the question of using DisableMetaDataCache - your latest Help states "The function may be called at any time but not from callback handlers". I have moved it to after the mount and the call then works. However, I am not certain that it resolves my problem as I am getting other spurious issues such as the file status being changed to Read Only when it plainly is not.

I am not using cbfs.notifydirectorychange because, the notification from the database that changes have occurred arises in the middle of applying an update as a result of a CBFSCloseFile event. Calling cbfs.notifydirectorychange at this point appears to trigger a call from Windows which locks because I am already in a 'locked' Windows process.

However, the nature of my prolem at this time, is that CBFS is provided woth a correct data length in the EnumerateDirectory. This is evident because Windows Properties is recording the correct length. However, when the file is subsequently opened, CBFS is calling the read with a length that is the same as when the file was 1st opened in the session. It appears that CBFS is NOT taking account of a change in file length even though it has enumerated the directory concerned.
#9990
Posted: 05/12/2009 08:58:49
by Volodymyr Zinin (EldoS Corp.)

Quote
Tim Hayes wrote:
On the question of using DisableMetaDataCache - your latest Help states "The function may be called at any time but not from callback handlers". I have moved it to after the mount and the call then works.

We will correct it.

Quote
Tim Hayes wrote:
However, I am not certain that it resolves my problem as I am getting other spurious issues such as the file status being changed to Read Only when it plainly is not.

Hm. Maybe there is an error somewhere in CallbackFS. But please check first, perhaps your code returns the Read Only attribute for the file (either during the parent directory enumeration or in the GetFileInfo callback).

Quote
Tim Hayes wrote:
I am not using cbfs.notifydirectorychange because, the notification from the database that changes have occurred arises in the middle of applying an update as a result of a CBFSCloseFile event. Calling cbfs.notifydirectorychange at this point appears to trigger a call from Windows which locks because I am already in a 'locked' Windows process.

NotifyDirectoryChange should work well. You can call it as from outside the callbacks as from inside. But in the last case it will be called asynchronously (i.e. the function returns immediately and the processing will take place by CallbackFS internal worker thread). Such processing prevents from deadlocks.

Quote
Tim Hayes wrote:
However, the nature of my prolem at this time, is that CBFS is provided woth a correct data length in the EnumerateDirectory. This is evident because Windows Properties is recording the correct length. However, when the file is subsequently opened, CBFS is calling the read with a length that is the same as when the file was 1st opened in the session. It appears that CBFS is NOT taking account of a change in file length even though it has enumerated the directory concerned.

This is because the file is still opened at the time when external changes for this file occurred. And disabling the meta-data cache doesn't help, because meta-data (file name, size and other attributes) associated with the file is not in the meta-data cache but is being used to support the currently opened file.
NotifyDirectoryChange should help in this case, but... if the file in this moment is really opened by someone to read/write data then a handle associated with this opening will become invalid and any i/o operations on it (except CloseHandle) will return with error.
#9995
Posted: 05/12/2009 10:32:37
by Tim Hayes (Standard support level)
Joined: 06/06/2007
Posts: 36

Thankyou for your helpful comments.

I failed to inform you that I had 2 client applications running on the same PC (for testing purposes to save me using 2 pc's). Each client created an instance of CBFS and mounted a virtual drive (difereent drive letters of course).

It appears that the first drive which had the file in update mode, became "corrputed" by reporting the file in read-only mode, only AFTER the second client opened up the same file in read-only mode.

I am wondering if the CBFS callback is a single instance which maybe confusing the two drives and treating the files which have the same pathname (apart from the drive letter)? So, the original client is for instance picking up the read-only status from the second client?

I will retest the system with clients on 2 different PCs and see if the results differ.
#10000
Posted: 05/12/2009 13:12:20
by Tim Hayes (Standard support level)
Joined: 06/06/2007
Posts: 36

Have noted a bug in my software that is responsible for the overwriting of the file attributes.

However, my main issue is now resolved after setting DisableMetaDataCache to true. It appears that this is certainly a new feature introduced since version 2.1 and the default operation is now "cached metadata" as opposed to "un-cached" which is the way CBFS used to operate.

Personally I feel it is dangerous to change default behaviour in a complex product like CBFS that other software is using. However that does not detract from still an excellent product and support. Thankyou.
Also by EldoS: SecureBlackbox
200+ components and classes for digital security, signing, encryption and secure networking.

Reply

Statistics

Topic viewed 3177 times

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




|

Back to top

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

Got it!