EldoS | Feel safer!

Software components for data protection, secure storage and transfer

RENAME throws a system exception

Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.
#6847
Posted: 07/06/2008 07:26:54
by Brian Wessberg (Basic support level)
Joined: 07/06/2008
Posts: 5

Hi,

Whenever I try to rename a file the system will throw the following exception at me:

Quote
An unexpected error is preventing the operation. Make a note of this error code, which might be usefull if you get additional help to resolve this problem:
Error 0x800705AA: Insufficient system resources exist to complete the requested service.


A "retry"-button will be presented - clicking this will succesfully rename the file. (When the OnRenameOrMoveFile event is not implemented the error will keep popping up on retry). Even though a user renaming a file would be able to continue his/her doings - any application trying to rename files would fail to complete due to this error.

I get no errors creating or deleting files.

I am using CBFSNet 2.0.34.29023 on a Vista Business machine.
I believe to have tried most combinations of
StorageType, CallAllOpenCloseCallbacks, UseSystemCache, AllowDelayedClose, AddMountingPoint, AddNetworkMountingPoint ..... but all with the same result.

I'v also tried older versions of CBFSNet.

Has anyone experienced this or simular kinds of errors???
Hints, Fixes, Solutions, Workarounds???

Kind Regards,
Brian

#6848
Posted: 07/06/2008 13:20:08
by Eugene Mayevski (EldoS Corp.)

Does the problem happen with the sample project(s) or with your code or both?


Sincerely yours
Eugene Mayevski
#6849
Posted: 07/06/2008 15:42:33
by Brian Wessberg (Basic support level)
Joined: 07/06/2008
Posts: 5

If I change the sample like this:

Quote
VirtualFile vfile = null, vdir = null;
FindVirtualFile(FileInfo.FileName, ref vfile);
FindVirtualDirectory(NewFileName, ref vdir);

vfile.Remove();

// vfile.Rename(GetFileName(NewFileName));//obtain file name from the path;

vdir.AddFile(vfile);


Removing the actual rename, then I will also get the error. It seems to accur in the following, where FileHandleContext is not allocated. (Error: Handle is not initialized.)

Quote
private void CbFsSetAllocationSize(object sender, CbFsFileInfo FileInfo, IntPtr FileHandleContext, Int64 AllocationSize)
{
VirtualFile vfile = (VirtualFile)GCHandle.FromIntPtr(FileHandleContext).Target;

vfile.AllocationSize = AllocationSize;
}



I get puzzled why this piece of code seems to do the trick - keeping FileHandleContext allocated??:

Quote
public void Rename(string NewName)
{
mName = NewName;
}


I tried to make my own code as close as posible to that of the sample. But in my own code FileHandleContext in CbFsSetAllocationSize is never allocated during rename :(

Any idea?

/Brian
#6851
Posted: 07/07/2008 03:27:00
by Vladimir Cherniga (EldoS Corp.)

Quote
Brian Wessberg wrote:
I get puzzled why this piece of code seems to do the trick - keeping FileHandleContext allocated??:


FileHandleContext should be allocated during Open/Create File callbacks and deallocated during CloseFile callback. If you not using FileHandleContext in such way this parameter is invalid in others callbacks.
In our Virtual Disk sample FileHandleContext represents each instance of VirtualFile class, you can use it or not in your own code, it depends on design.
If you have problems with your code, not with distributed samples, provide some code to debug.
#6855
Posted: 07/07/2008 06:21:08
by Brian Wessberg (Basic support level)
Joined: 07/06/2008
Posts: 5

Basicly I took the sample(VDisk) and extended it to meet my needs...(Streaming in and out of a database)

I am using the same mechanism for FileHandleContext as in the sample - also with a VirtualFile-class.

It is only during "Rename" that FileHandleContext is empty in CbFsSetAllocationSize.

As I stated above - I can make the sample act the same way as my own code by removing one line of code:

In CbFsRenameOrMoveFile:
vfile.Rename(GetFileName(NewFileName));//obtain file name from the path;

So you could easily replicate my error. The problem is, looking at the code behind vfile.Rename(), I can't seem to figure why this would result in an error. If you could give me a hint on why this fails - I might be able to understand what I am missing in my own code. (Offcause it's related to the fact that the new file-name does not exists - but where in the sample does the link collaps?)

My own code is hooked to a database so not that easy to just sent it to you for debugging. :(

/Thanks so far :D
/Brian
#6856
Posted: 07/07/2008 06:51:40
by Brian Wessberg (Basic support level)
Joined: 07/06/2008
Posts: 5

I mean - even if the vFile is not renamed - the FileHandleContext should still be pointing to the same instance of vFile, right? Why is the link broken?

/Brian
#6857
Posted: 07/07/2008 08:18:13
by Eugene Mayevski (EldoS Corp.)

Unfortunately both me and Vladimir are having hard time trying to understand what's wrong on your side. Can you please post the code (the complete CPP file) that causes the problem?


Sincerely yours
Eugene Mayevski
#6859
Posted: 07/07/2008 09:39:48
by Vladimir Cherniga (EldoS Corp.)

Quote
Brian Wessberg wrote:
I mean - even if the vFile is not renamed - the FileHandleContext should still be pointing to the same instance of vFile, right? Why is the link broken?


There are CloseFile callback invoked for source file before RenameOrMoveFile callback triggered and OpenFile callback for destination file invoked after RenameOrMove. So you cannot open file in post rename process, because vfile.Remove() delete the file from directory listing. At that moment, when SetFileAllocationSize invoked after OpenFile callback, FileHandleContext already zeroed in CloseFile callback.
#6870
Posted: 07/08/2008 03:11:20
by Brian Wessberg (Basic support level)
Joined: 07/06/2008
Posts: 5

Thanks, I believe that got me further.

What I failed to understand was that it's the scope of the new file's FileHandleContext that's missing. Debugging the sequence you descriped let me see that I never recieve the "OpenFile callback" for the new file at this point.

I will look into this and return if I need further assistance. ;)

/Thx again :)
/Brian


Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages

Reply

Statistics

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