EldoS | Feel safer!

Software components for data protection, secure storage and transfer

ContextHandle broken after error in OnRenameOrMove callback

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#21872
Posted: 10/08/2012 12:57:41
by Ivan P (Priority Standard support level)
Joined: 04/11/2011
Posts: 66

I've got a situation when context handle allocated for opened file becomes invalid after unsuccessful attempt to rename a file.

My handler for OnRenameOrMove callback currently throws ECBFSError(ERROR_CALL_NOT_IMPLEMENTED), because it's not implemented yet.

When a program (Far Manager) tries to rename a file it first opens it, and a context handle is allocated in my code using GCHandle.Alloc(). The Target for this GCHandle is an object of my own ContextHandle type.


After unsuccessful rename attempt the OnFileOpen callback is called but with the IntPtr conext that was already deallocated in some previous OnClose callback.
And the target of this context is ECBFSError object thrown in rename callback, rather than my allocated ContextHandle object.

I attached the snippet from the log file that shows that context was deallocated because it was a final close for an object. The value passed to next OnOpen call seems to be a pointer reusage, but not the context allocated by me.

Is it expected behavior? How should I handle this situation?


Thanks,
IP

OS: Win7 x64
CBFS: 3.2.115
CallAllOpenCloseCallbaks set to true (if it matters)


[ Download ]
#21875
Posted: 10/08/2012 14:17:26
by Vladimir Cherniga (EldoS Corp.)

Do you force FileInfo->HandleContext = IntPtr::Zero in last OnCloseFile callback ?
#21876
Posted: 10/08/2012 14:54:08
by Ivan P (Priority Standard support level)
Joined: 04/11/2011
Posts: 66

Thanks for your answer, that works.

I didn't know I have to do this. Could you update the HTML help doc? Because even CbFsFileInfo class description in the help file doesn't have this field.

Actually I'm using .Net API and some callbacks (OnCbfsCloseFile, OnSetEndOfFile, OnCbfsWriteFile, and others) have 2 parameters: CbFsFileInfo fileInfo (which has HandleContext property) and IntPtr fileHandleContext.

I'm not sure which one of them to use, so I use fileHandleContext.

Some callback handlers have only the CbFsFileInfo parameter, so there's no ambiguity.

Sincerely,
IP
#21877
Posted: 10/08/2012 15:14:14
by Eugene Mayevski (EldoS Corp.)

Quote
Ivan P wrote:
I didn't know I have to do this. Could you update the HTML help doc? Because even CbFsFileInfo class description in the help file doesn't have this field.


It doesn't make sense to check the value of context in OnFileOpen so clearing the variable is not needed really.

In CBFS 4 the ambiguity between CbFs***Info and HandleContext is resolved - UserContext is only a member of CbFs***Info and not a separate parameter.


Sincerely yours
Eugene Mayevski
#24624
Posted: 04/18/2013 12:41:50
by Ivan P (Priority Standard support level)
Joined: 04/11/2011
Posts: 66

We are moving to CBFS4.

Do I still have to set fileInfo.UserContext to IntPtr.Zero on the last close?
And do I need to set hadnleInfo.UserContext to IntPtr.Zero on each close?

Thanks,
Ivan
#24625
Posted: 04/18/2013 13:53:45
by Vladimir Cherniga (EldoS Corp.)

Quote
Do I still have to set fileInfo.UserContext to IntPtr.Zero on the last close?
And do I need to set hadnleInfo.UserContext to IntPtr.Zero on each close?

No. Now it does handled properly in callbacks internal implementation.
#24698
Posted: 04/26/2013 10:09:06
by Ivan P (Priority Standard support level)
Joined: 04/11/2011
Posts: 66

One more question about contexts.

We switched to CBFS4, and noticed some strange behavior.
The OnCbfsDelete callback has a CbfsFileInfo parameter.
From what I've seen the Delete callback is always called after the last Close call, and the context is released at this point.

We've never used this before, but our code stub was trying to obtain the object from CbfsFileInfo.Usercontext. In CBFS3 this has never caused ant problem, but in CBFS4 it returns either IntPtr.Zero (which is normal) or (sometimes) it returns some invalid object of type 'System.Threading._TimerCallback'

Should we look at the FileInfo.UserContext in the DeleteFile callback at all?
Are there any cases when Userconext field can contain something valid?
#24699
Posted: 04/26/2013 10:54:48
by Vladimir Cherniga (EldoS Corp.)

Quote
Should we look at the FileInfo.UserContext in the DeleteFile callback at all?
Are there any cases when Userconext field can contain something valid?

It should be ignored, because this is the same value that was used in FileInfo.UserContext on the last close file callback. If you free context from the last close callback, then it could be ignored, or you may save something valuable, that can be detected in Delete callback, but this value will be lost, if file not deleted on the last close.
#24701
Posted: 04/26/2013 11:49:56
by Ivan P (Priority Standard support level)
Joined: 04/11/2011
Posts: 66

Thanks,

And still fighting the contexts :)

Sometimes when in OpenFile call the FileInfo.UserContext contains the Exception object. It's impossible in our code to allocate .UserContext for anything other than CbfsHandle object (its our calss, and this is the only class that can be assigned to UserContext).

This seems to happen after rename. I just created new text document in Windows Explorer and tried to give it a name (to rename it).

Here's a log snippet for all CBFS4 calls. Look that after the last close (FINAL) and Moving the file the same context pointer is passed to OpenFile in the CbfsFileInfo.Context handle.

Code
INFO  - [explorer: 3696:52]: Open: '\New Text Document.txt' , ctx:00000000, access/share:[00110080:0007] - [READ_ATTRIBUTES, DELETE, SYNCHRONIZE]:[READ, WRITE, DELETE]
INFO  - [explorer: 3696:52]: Opened: '\New Text Document.txt' (ctx:003A2DC8)
INFO  - [explorer: 3696:54]: GetInfo: '\234234234.txt'
INFO  - [explorer: 3696:54]: GetInfo: '\234234234.txt' - NOT FOUND
INFO  - [explorer: 3696:56]: Open: '\' , ctx:00000000, access/share:[00100002:0003] - [WRITE_DATA, SYNCHRONIZE]:[READ, WRITE]
INFO  - [explorer: 3696:56]: Opened: '\' (ctx:003A2DE0)
INFO  - [explorer: 3696:58]: GetInfo: '\234234234.txt'
INFO  - [explorer: 3696:58]: GetInfo: '\234234234.txt' - NOT FOUND
INFO  - [explorer: 3696:60]: Close: '\New Text Document.txt', (ctx:003A2DC8,attr:2097184)
INFO  - [explorer: 3696:60]: Closed(FINAL): '\New Text Document.txt' (ctx:003A2DC8)
INFO  - [explorer: 3696:60]: Move: '\New Text Document.txt' (attr:2097184), to '\234234234.txt'
INFO  - [explorer: 3696:60]: Move: '\New Text Document.txt' - MOVED TO  '\234234234.txt'
INFO  - [explorer: 3696:60]: Open: '\234234234.txt' , ctx:003A2DC8, access/share:[00110080:0007] - [READ_ATTRIBUTES, DELETE, SYNCHRONIZE]:[READ, WRITE, DELETE]
ERROR - [explorer: 3696:60]: OpenFile '\234234234.txt'
System.InvalidCastException
Unable to cast object of type 'System.Threading._TimerCallback' to type 'CbfsHandleContext'.


You can see that '\New text file.txt' was opened once (with allocating 003A2DC8 context for it) and then closed with releasing allocated context.

Then file has been renamed to '\234234234.txt' and you can see that very first OpenFile call does have the context (that was released).

It seems that I still have to set context to IntPtr.Zero on the last close (doing this solves the issue)
Notice that we do not use HandleInfo contexts yet.
#24704
Posted: 04/26/2013 13:15:54
by Vladimir Cherniga (EldoS Corp.)

It seems that UserContext wasn't cleanup on last close callback during rename operation. With an attached lib file it should behave properly (zipped).


[ Download ]
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

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