EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Unexpected Windows Explorer error with drag-and-drop file operation

Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.
#20018
Posted: 05/02/2012 14:34:11
by Mel Reyes (Standard support level)
Joined: 03/28/2011
Posts: 10

My file system is currently fully-functional for read access. I would also like to allow some restricted write access to certain folders.

I can successfully create new files and edit them with native applications such as notepad and mspaint. All the changes are being persisted to my data store correctly in this situation.

I am experiencing unexpected behavior when trying to drag a file from my desktop into the file system, however. I can see that the "create" even fires and is handled properly, a 0-byte file appears in the explorer Window, and then an error message is displayed: "Can't read from the source file or disk."

All the permissions seem to be set correctly (I have the file set to Everyone, Full Access). I don't see any unexpected errors occurring within my callback functions. It may also be worth mentioning that if I right-click, "create new", open the file, I can copy/paste the data from the source file and save it successfully. (I am not sure why this should have a different result compared with drag/drop of the file from desktop though!)

Any help to understand what I am doing wrong is appreciated. The sequence of operations observed from CBFS is as follows:

- GetFileInfo on target file (result: file not found)
- CreateFile on target file (result: file created and handle opened)
- CloseFile on target file (result: buffers flushed and handle closed)
- OpenFile on target file with write access requested (result: handle opened)
- SetAllocationSize (silently ignored, we have no concept of allocation size on the backing store)
- SetEndOfFile (EndOfFile = 0, result: file in backing store is already 0 bytes, no changes made)
- SetFileAttributes (silently ignored)
- GetVolumeSize (returns long.MaxValue)
- OpenFile on parent folder of target file (result: handle opened)
- EnumerateDirectory on parent folder of target file (files enumerated correctly including the target file)
- CloseEnumeration on parent folder
- CloseFile on parent folder
- CloseFile on target file
- OpenFile on target file
- CloseFile on target file
- DeleteFile on target file
#20022
Posted: 05/03/2012 00:52:57
by Volodymyr Zinin (EldoS Corp.)

Hello Vincent,

Perform the following:

1. Take Process Monitor fr om http://technet.microsoft.com/en-us/sy...s/bb896645
2. Execute it and set there the filter to include only the drive wh ere the problem occurs, i.e.:
"Path" - "begins with" - "X:" - include
3. In the program's toolbox there are buttons used to show/hide registry and network activity. Uncheck them to hide these activity.
4. Reproduce the problem.
5. Stop logging.
6. Look for operations that are finished with error near the end of the log and approximate it to the CallbackFS callbacks.
7. If you are not able to find the reason of the problem then save the log to a file (in the process monitor native format) and send it to us (with information what a file is being copied and another information you may think is important).
#20034
Posted: 05/03/2012 09:44:16
by Eric Dahlvang (Standard support level)
Joined: 09/11/2009
Posts: 29

In your sequence of operations, you have the following:
...
SetAllocationSize (silently ignored, we have no concept of allocation size on the backing store)
...
- SetFileAttributes (silently ignored)
...
EnumerateDirectory on parent folder of target file (files enumerated correctly including the target file)
...

If you are ignoring SetAllocationSize and SetFileAttributes, then you would not be returning the correct allocation size and file attributes when the file is returned by EnumerateDirectory. Windows expects to receive back a file with the same properties it had previously given you. I would guess that this is your problem. You cannot ignore setting the allocation size, and file attributes.
#20035
Posted: 05/03/2012 09:48:51
by Mel Reyes (Standard support level)
Joined: 03/28/2011
Posts: 10

Hi Vladimir,

Thank you for your assistance. Using the ProcMon tool I was able to find the source of the error pretty quickly.

I was able to determine that, in C#, when responding to the GetVolumeSize event, setting the TotalAllocationUnits and/or AvailableAllocationUnits too high will cause an error. What is the maximum values that can be safely placed in these parameters?

Thanks,

Vincent
#20037
Posted: 05/03/2012 09:59:39
by Mel Reyes (Standard support level)
Joined: 03/28/2011
Posts: 10

Hi Erik,

Thanks for your reply. Our backing store does not have a concept of allocation size. The allocation size returned by our implementation is always the same as the file size. This does not appear to be causing any problems currently.

Similarly, we cannot store hidden/system attributes, so we ignore them. We do store and act on the "Directory" attribute. We also force immutable attributes for some file system objects. This also does not appear to be causing any problems.

In this particular case, Windows was confused about the available space on the disk so it decided to truncate and then delete the file.

Thanks,

Vincent

Quote
Eric Dahlvang wrote:
In your sequence of operations, you have the following:
...
SetAllocationSize (silently ignored, we have no concept of allocation size on the backing store)
...
- SetFileAttributes (silently ignored)
...
EnumerateDirectory on parent folder of target file (files enumerated correctly including the target file)
...

If you are ignoring SetAllocationSize and SetFileAttributes, then you would not be returning the correct allocation size and file attributes when the file is returned by EnumerateDirectory. Windows expects to receive back a file with the same properties it had previously given you. I would guess that this is your problem. You cannot ignore setting the allocation size, and file attributes.
#20048
Posted: 05/04/2012 01:38:29
by Volodymyr Zinin (EldoS Corp.)

Quote
Vincent Ugenti wrote:
I was able to determine that, in C#, when responding to the GetVolumeSize event, setting the TotalAllocationUnits and/or AvailableAllocationUnits too high will cause an error. What is the maximum values that can be safely placed in these parameters?

long.MaxValue should work. Perhaps some components code checks the file system's name and confuses if the volume size is greater than the allowed for the specified file system.
Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.

Reply

Statistics

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