EldoS | Feel safer!

Software components for data protection, secure storage and transfer

dwCreationDisposition

Also by EldoS: SecureBlackbox
200+ components and classes for digital security, signing, encryption and secure networking.
#24758
Posted: 04/30/2013 13:53:58
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Hello all, long time no speak. I have a fairly technical question for Vladimir or one of the other developers. The CbFsCreateFile or CbFsOpenFile callbacks seem to be pass throughs for the CreateFile API in Windows. I haven't looked at your source code to try to determine if this is true or not, but both of your callback functions have incoming parameters, dwDesiredAccess and dwSharedMode, that mimic the calling parameters of the CreateFile API in Windows, so it seems to make sense that your driver intercepts calls to CreateFile and gives control the one of these callback routines. My guess is that you interrogate the dwCreateDisposition parameter and call CbFsCreateFile for files that people want to create, and CbFsOpenFile for files that people just want to open. There is a potential problem with this, if the file already exists, then it seems like you always call CbFsOpenFile, but what if the user wants to overwrite the file rather than just open it? Another potential problem that I ran across is that my database system has a background way of deleting files from my virtual disk without telling Windows about it, and if one of my users is savvy enough to do that, then the next time he tries to create that file using Windows explorer drag and drop, Windows thinks it is still there, so I get an error in my CbFsOpenFile callback, that is hard for me to recover from.

Is it possible for you to add the dwCreateDisposition parameter to both the CbFsOpenFile and CbFsCreateFile callbacks, so we have a better understanding of what it is the caller really wants to do?
#24759
Posted: 04/30/2013 14:33:56
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I searched your forum and I saw that someone else had already asked this question and Eugene said it might be done in Release 4. Was it done in Release 4?
#24760
Posted: 05/01/2013 00:55:52
by Volodymyr Zinin (EldoS Corp.)

dwDesiredAccess and dwSharedMode were added rather for informational purpose. It isn't required additional processing with it if you don't need it. CallbackFS processes itself these parameters. But if in your CallbackFS implementation "backend files" can be opened outside the CallbackFS callbacks then perhaps you can use these parameters to control access to these files.

About dwCreateDisposition. In order to simplify the CallbackFS callbacks this parameter is processed internally. I.e. when a create/open request occurs CallbackFS first checks in its metadata cache whether the file is present. If there is no such information then calls the OnGetFileInfo callback. And then calls either OnCreate or OnOpen callbacks. In addition, if it's required to recreate file then additional OnSetFileSize(0) and OnSetFileAttributes() are called too.

Quote
Sid Schipper wrote:
Another potential problem that I ran across is that my database system has a background way of deleting files from my virtual disk without telling Windows about it, and ...

Maybe switching the metadata cache off helps. In algorithm I described above the OnGetFileInfo and OnCreate/OnOpen callbacks are called synchronously. So if the metadata cache is not used and the file isn't currently opened (by this or another program in parallel) then you always get OnGetFileInfo callback before the OnCreate/OnOpen one.
#24761
Posted: 05/01/2013 10:42:17
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Thank you, Vladimir. So, what you are saying is that in the cases that I am concerned about I can put the logic I need into the OnGetFileInfo callback and that will save me from the problems I have? That seems logical to me and I'm pretty comfortable with it, but I'd still like some confirmation from you that I am reading your messages clearly.
#24762
Posted: 05/01/2013 11:11:19
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Another thing that would be nice is if there was some way to customize the error messages put out by Windows after I throw an ECBFSError. I'll give you an example, when I throw an ERROR_FILE_NOT_FOUND error Windows displays a message that says "Cannot read from source file". I would prefer to put out something that is more to the point, like "File not found" or something similar. The Windows message implies that I was trying to read from the file when in reality I was just trying to open it. I realize this is sort of nit-picking, so I won't be that upset if your answer is no way, Jose.
#24763
Posted: 05/01/2013 11:36:44
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Here is another interesting one. I just ran into a case where I threw a new ECBFSError(2) and Windows did not display any error message at all. Any idea as to why that would happen?
#24766
Posted: 05/01/2013 14:40:19
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Here is another question for Vladimir. Could you explain to me the sequence of CbFs callbacks that occur when a user does a View->Refresh in Windows Explorer? I guess I could run Process Explorer myself to see this, but I thought if Vladimir knew it already off the top of his head he could help me.
#24769
Posted: 05/02/2013 01:52:57
by Volodymyr Zinin (EldoS Corp.)

Quote
Sid Schipper wrote:
So, what you are saying is that in the cases that I am concerned about I can put the logic I need into the OnGetFileInfo callback and that will save me from the problems I have?

It helps in the case the metadata cache is disabled and the requested file isn't currently opened. In the last case CallbackFS already knows that the file exists.

Quote
Sid Schipper wrote:
Another thing that would be nice is if there was some way to customize the error messages put out by Windows after I throw an ECBFSError. I'll give you an example, when I throw an ERROR_FILE_NOT_FOUND error Windows displays a message that says "Cannot read from source file". I would prefer to put out something that is more to the point, like "File not found" or something similar. ....

CallbackFS converts win32 errors you returned/throws from the callbacks to "status" errors, because in the kernel (where the CallbackFS driver works) such type of errors is used. It's done by the use of our Error2NtStatus function, because there isn't such conversion mechanism in the system (there is only an opposite conversion). Listing of this function is attached to this message. If you want some additional error conversions to be added then tell us and we will add it in future builds.
About the ERROR_FILE_NOT_FOUND error. It's converted to STATUS_NO_SUCH_FILE. And the error description you specified doesn't correspond to this error. Most probably it's the program, which performs copying, interprets the copy failure in such a way. You can use Process Monitor to see what happens in this case.

Quote
Sid Schipper wrote:
I just ran into a case where I threw a new ECBFSError(2) ...

Error 2 means ERROR_FILE_NOT_FOUND, which is converted to STATUS_NO_SUCH_FILE.

Quote
Sid Schipper wrote:
Could you explain to me the sequence of CbFs callbacks that occur when a user does a View->Refresh in Windows Explorer?

1. A directory to enumerate is opened. If the metadata cache isn't used and the directory isn't already opened (in parallel by this or another process) then the OnGetFileInfo callback is called. Then the OnOpen callback is called.
2. Several calls of the OnEnumerateDirectory callback.
3. The OnClose callback is called.


[ Download ]
#24796
Posted: 05/02/2013 18:52:54
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Thank you, Vladimir. I turned off the metadata cache and that basically solved my whole problem, because I was already handling the FILE not found error in OnGetFileInfo. The reason my logic was never hit was that the metadata cache interfered with that process. Because my files are really my database objects the metadata cache does not apply to them. I also do not take a performance hit by doing this because we cache the metadata for our database objects ourselves. Our cache serves as a mechanism to prevent excessive calls to the equivalent of the GetFileInfo (which we call srb_stat, mimicking the UNIX stat call).

As usual you have been very helpful.

PS - To Eugene. My manager has put in a request for funding to buy version 4. Unfortunately, with all the red tape we have to go through to get that funding it could take as long as 6 months to get the money. But, once we do we will definitely be purchasing Version 4.
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 1483 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!