EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Meaning of DesiredAccess

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
#7563
Posted: 09/09/2008 18:53:37
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I have been logging the values that you pass into the CbFsOpenFile callback for the DesiredAccess and they do not seem to make sense. If I right click and open a text file on my virtual disk, which should use notepad to open the file, at CbFsOpenFile time the DesiredAccess is 0x0080, which the Windows documentation says is FILE_READ_ATTRIBUTES. Shouldn't it be FILE_READ_DATA at that point?
#7566
Posted: 09/10/2008 01:12:44
by Volodymyr Zinin (EldoS Corp.)

Is the CallbackFileSystem.CallAllOpenCloseCallbacks property set or not? If it isn't set then you obtain only Open callback for the first opening that can be with FILE_READ_ATTRIBUTES access.
#7575
Posted: 09/10/2008 10:18:54
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

We cannot set CallAllOpenCloseCallbacks because when we do it slows down the system to a crawl and makes it totally useless.
#7576
Posted: 09/10/2008 11:48:54
by Eugene Mayevski (EldoS Corp.)

Hmm. Are you attempting to open/close backend data storage on each file open/close operation? If yes, this is indeed slow. The solution is to set CallAllOpenCloseCallbacks to true AND make an internal counter and open the file only on first open callback and close it on last close callback. This will be fast and you still will be notified about all open/close operations but you won't get slowdown. When you set CallAllOpenCloseCallbacks to false, the CBFS API creates an internal counter (to do what I described above).


Sincerely yours
Eugene Mayevski
#7590
Posted: 09/12/2008 13:57:07
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I set the CallAllOpenCloseCallbacks to TRUE again and I found that the performance was not slow because our application handled the opening of the files the way you described above.

But, when I looked at my logs I found another very curious symptom that is causing us all sorts of grief. When I initially right click on the file I get two calls to CbFsCloseFile, where the calling process in both cases is Windows Explorer. After I close the file the first time, I free the memory that I am placing in the File Handle Context when I open the file. There is no call to CbFsOpenFile in between the two calls to CbFsCloseFile and the second one has the same FileHandleContext, which I have already freed. This does not make sense to me.
#7591
Posted: 09/12/2008 15:01:26
by Volodymyr Zinin (EldoS Corp.)

Quote
Sid Schipper wrote:
There is no call to CbFsOpenFile in between the two calls to CbFsCloseFile

But perhaps there had been two consecutive OnCreate/OnOpen calls before those two OnClose calls. Please check it up. If quantity of OnCreate/OnOpen calls aren't equal to quantity of OnClose calls for the same file then there is a bug somewhere.
In the case when CallAllOpenCloseCallbacks is true, it's necessary to have in FileHandleContext some "open file" counter. It must be incremented in each OnCreate/OnOpen calls and decremented in each OnClose calls. And FileHandleContext can be deleted only after the counter is set to 0 in some OnClose call.
#7592
Posted: 09/12/2008 15:56:57
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I also noticed there is some confusion in the documentation and in my messages to you and Eugene about the setting of the CallAllOpenCloseCallbacks flag. When I set it TRUE, I am assuming that means that the Callbacks get called for every open and close, and when it is set to FALSE, that means that the callbacks only get called on the first open and the last close. Is that your understanding also?
#7595
Posted: 09/13/2008 00:16:52
by Eugene Mayevski (EldoS Corp.)

Yes, you described it right.


Sincerely yours
Eugene Mayevski
Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.

Reply

Statistics

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