EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Context and renaming

Also by EldoS: SecureBlackbox
200+ components and classes for digital security, signing, encryption and secure networking.
#15114
Posted: 11/24/2010 03:54:26
by Robert Baer (Basic support level)
Joined: 11/08/2010
Posts: 46

Hello,

I have a problem with the FileHandleContext when a file is renamed (CallAllOpenCloseCallbacks is set to true):

1) create file x (desired access = 00100080, no generic rights specified)
2) rename file x to y
3) open file y (desired access: generic right GENERIC_READ specified)
4) close file handle of step 3
5) close file handle of step 1

This is what happens to the FileHandleContext during these steps:
1) null context passed to the method -> new context A is created
2) nothing
3) null context passed to the method -> new context B is created
4) context B passed to the method -> context B gets destroyed as it isn't used anymore
5) context B passed to the method -> context B is not valid anymore, context A expected

I think something goes wrong within step 3: As the context A still exists for the file, it should be passed to the open-callback. What do you think?

Please note that the behavior is different when creation in step 1 is performed with a GENERIC_READ access. In this case the file can't be renamed.

Regards,
Robert
#15120
Posted: 11/24/2010 10:40:45
by Vladimir Cherniga (EldoS Corp.)

Hello,
which CBFS version did you use ? Do you have a problem with one of the samples from installation package ?

Best regards,
Valdimir Cherniga.
#15133
Posted: 11/26/2010 07:29:49
by Robert Baer (Basic support level)
Joined: 11/08/2010
Posts: 46

Hello,

I am using CBFS version 3.0.78. The problem doesn't occur in the sample VDisk as the CbFsCloseFile callback doesn't handle the FileHandleContext.

I am using a workaround to handle the problem now: When there is no context passed to OpenFile in step 3, I am searching for an adequate context in a list.

Regards,
Robert
#15138
Posted: 11/26/2010 10:06:50
by Vladimir Cherniga (EldoS Corp.)

Do you have the same issue with a Mapper sample ? It use the same technique handling UserContext in callbacks with CallAllOpenCloseCallbacks property set to TRUE.
#15148
Posted: 11/29/2010 02:06:30
by Robert Baer (Basic support level)
Joined: 11/08/2010
Posts: 46

Hello,

the behaviour is different with the Mapper sample. When I start it with CallAllOpenCloseCallbacks property set to true, renaming (step 2) is not possible (error -32). But when I close the created file afterwards, I get the following assertion:

Program: ...ile System\Samples\CPP\Mapper\Debug\Mapper.exe
File: ...eldos\callback file system\samples\cpp\mapper\mapper.cpp
Line: 1069
Expression: CBFS_NTC_FILE_CONTEXT == NodeType(Ctx)

Strangely, renaming is possible with CallAllOpenCloseCallbacks set to false (which has to be true to reproduce my issue).

Regards,
Robert
#15171
Posted: 11/30/2010 11:50:12
by Vladimir Cherniga (EldoS Corp.)

Hello,
to fix the issue with renaming the file in step 2 you should add FILE_SHARE_DELETE flag in CreateFile() win32api invoked from OpenFile/CreateFile callbacks. But there is a bug in the cbfs user mode library code that is force UserContext to NULL in rename callback by mistake (this error only raise when CallAllOpenCloseCallbacks is set to true). We are going to fix the issue asap. The only changes in sample code(like Mapper sample or others) will referes to the CloseFile callback and OpenFile/CreateFile callbacks. Don't forget to review the samples code after the fix will be available.
#15274
Posted: 12/12/2010 03:11:02
by Ion Silvestru (Standard support level)
Joined: 08/05/2010
Posts: 9

Quote
Vladimir Cherniga wrote:
Hello,
to fix the issue with renaming the file in step 2 you should add FILE_SHARE_DELETE flag in CreateFile() win32api invoked from OpenFile/CreateFile callbacks. But there is a bug in the cbfs user mode library code that is force UserContext to NULL in rename callback by mistake (this error only raise when CallAllOpenCloseCallbacks is set to true). We are going to fix the issue asap.


Is this fixed in the 3.1.83 version?
#15275
Posted: 12/12/2010 06:49:33
by Eugene Mayevski (EldoS Corp.)

If you look at the dates, the answer was given later than build 83 was released.


Sincerely yours
Eugene Mayevski
#15276
Posted: 12/12/2010 06:59:31
by Vladimir Cherniga (EldoS Corp.)

Not yet, the fix will be available in the next build.
#15282
Posted: 12/13/2010 03:42:57
by Ion Silvestru (Standard support level)
Joined: 08/05/2010
Posts: 9

Quote
Eugene Mayevski wrote:
If you look at the dates, the answer was given later than build 83 was released.

Yes, but your developers are usually very fast, and I think it's your release policy which adds delay :)
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.

Reply

Statistics

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