EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Open Close File confirmation

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
#5472
Posted: 03/17/2008 19:08:56
by Vijay Mani (Standard support level)
Joined: 03/09/2008
Posts: 29

Hi,
We're using CBFS Version 1.2.20, CPP libraries.
We're implementing a virtual filesystem that is backed by a local server.
Unfortunately for our scenario, we cannot set AllowDelayedClose to true since we might might need to delete the files outside of the virtual filesystem, in which case having an open file handle will cause it to fail.

But, somewhat as expected, when settings AllowDelayedClose to false, we get quite a few open & close file requests (even after setting SetCallAllOpenAndCloseCallBack(FALSE) (we don't see a difference from TRUE)), of the order of 40 or so open & close calls per folder upon navigation into that folder. This is slowing us down quite considerable, and while there are some caching solutions we are investigating, we just want to make sure that this number of open/close calls is expected (in the ballpark), and we aren't missing something obvious.

Thanks.
#5476
Posted: 03/18/2008 02:06:55
by Volodymyr Zinin (EldoS Corp.)

Hello,

For obtaining all open/close requests you must set AllowDelayedClose to false and SetCallAllOpenAndCloseCal­lBack to true. Perhaps there is some bug in our CPP code, so we will recheck it now.
Also the system cache manager usually create own references to files that are opened by user or system programs and hold these references for a quite long time after the files are closed. It does so because it expects that the files will be reopened shortly and their data will have already cached. So the close requests (i.e. OnClose callback) for a lot of files do not call immediately, even if AllowDelayedClose is set to TRUE. To force the closing these files you should call ReleaseUnusedFiles.

But the number of open requests is always equal the number of close ones.
#5489
Posted: 03/18/2008 11:48:25
by Volodymyr Zinin (EldoS Corp.)

Quote
Vladimir Zinin wrote:
Perhaps there is some bug in our CPP code, so we will recheck it now.

We have checked it and haven't discovered any errors.
#5491
Posted: 03/18/2008 12:00:53
by Eugene Mayevski (EldoS Corp.)

Are you "navigating to this folder" with Windows Explorer? This piece of ... software attempts to read the thumbnails and file-specific info from the files by opening them all.


Sincerely yours
Eugene Mayevski
#5495
Posted: 03/18/2008 12:48:05
by Vijay Mani (Standard support level)
Joined: 03/09/2008
Posts: 29

Yes, we notice the large # of opens(& corresponding closes) when browsing through windows explorer.
If it were opening different files contained in the folder that would be 'expected'. But the folder is what is opened and closed numerous times.
Thanks for your help & quick responses.
#5500
Posted: 03/18/2008 13:30:10
by Eugene Mayevski (EldoS Corp.)

We are working on a workaround for this Explorer problem now. There exists a workaround that you can implement in your code, but it looks like we will have to create a couple of supplementary drivers to have this workaround right in our driver.


Sincerely yours
Eugene Mayevski
#5924
Posted: 04/17/2008 20:51:31
by Vijay Mani (Standard support level)
Joined: 03/09/2008
Posts: 29

Hi Guys,
In our virtual FS, we're currently using the system cache, and when we need to release unused files we call ReleaseUnusedFiles.
This mostly works, except sometimes, while we are still editing the file opened through the virtual FS, the file handle could be closed and opened again. Is this by design? Could it be because of our mode of opening the files?
desiredAccess = GENERIC_READ | GENERIC_WRITE : GENERIC_READ;
shareAccess = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE ;

Also is it by design that CBFS openfile call back doesn't pass an open-mode? It makes sense that if it's an OS/explorer open Vs app open we could open with different access flags.

Thanks.
#5925
Posted: 04/18/2008 01:28:17
by Eugene Mayevski (EldoS Corp.)

Quote
Vijay Mani wrote:
This mostly works, except sometimes, while we are still editing the file opened through the virtual FS, the file handle could be closed and opened again.


Use GetOriginatorProcessName function to find out, what process closes your file in the middle of operation.

Quote
Vijay Mani wrote:
Also is it by design that CBFS openfile call back doesn't pass an open-mode? It makes sense that if it's an OS/explorer open Vs app open we could open with different access flags.


This will be fixed in upcoming CBFS 1.5.


Sincerely yours
Eugene Mayevski
#5927
Posted: 04/18/2008 05:08:56
by Volodymyr Zinin (EldoS Corp.)

Quote
Vijay Mani wrote:
... the file handle could be closed and opened again. Is this by design?

Some programs can close handles to files that are edited by them. And reopen again only to write modifications.
#6065
Posted: 05/01/2008 16:38:10
by Vijay Mani (Standard support level)
Joined: 03/09/2008
Posts: 29

Intersting. I'm not sure if it's a bug in our code or in the way CBFS calls the open and close callbacks. But I notice an interesting descrepency.
So I open a word document on ntfs, and then use process explorer to check open file handles, I notice that word holds a handle to the file.<as expected> and when I close the file the file handle is released.

But in our virtual FS (which essentially opens files from a cache dir),when i open a word document, I don't see any open file handles. We currently have AllowDelayedClose set to false. And soon after the file is opened I notice an open and close call(multiple in fact).
When we use the default value of AllowDelayedClose(TRUE), we notice that when the file is opened there is a file handle, but when it is closed the file handle is not closed. (this is as expected since it is cached) but it still behaves differently from the native FS. Is is at possible to mimic the ntfs behaviour? i.e keep a file handle open when the file is opened in the editor, close it when the file is closed. We primarily just care about this working for word.
Thanks.
Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.

Reply

Statistics

Topic viewed 9755 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!