Restoring a file from the recycle bin creates a directory instead [mirror sample also]

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Delete a file using the explorer, it goes in the recycle bin
2. Restore the file
3. Check your file, you get a directory named after the file instead.

What is the expected output? What do you see instead?
The file should be restored correctly.
It seems like there's a '\\' happened at the end of the filename.

What version of the product are you using? On what operating system?
Current code repository (latest at the time of this writing)

Please provide any additional information below.
I get the same behavior in my own filesystem. Mirror samples does that too.

Thank for any help regarding that.

Original issue reported on code.google.com by fmi...@gmail.com on 21 Jan 2010 at 5:10

[GoogleCodeExporter]

I've noticed another defect with the recycle bin, deleting a directory with 
files in 
it just does not work. All the files are copied to the recycle bin correctly, 
but 
then, DeleteOnClose being never set, the original files never get deleted. They 
appear deleted from the explorer window, but as soon as you hit F5, they're 
back.
Tested on the latest set of code. (29/01/2010)
I forgot to mention to all this was with Windows XP.

Any clue ? Should I do something special with the "DELETE" createFile 
accessMode ?
Any help welcome!
Thanks

Original comment by fmi...@gmail.com on 29 Jan 2010 at 2:58

[GoogleCodeExporter]

Hello,
Thank you for your bug report. The first issue, when you restore a file, the 
file 
become a directory, was fixed. In the latest version r74, I can reproduce the 
second 
issue, files in a directory are deleted but the directory is not deleted. 

Original comment by asa...@gmail.com on 3 Feb 2010 at 9:36

[GoogleCodeExporter]

Hello,
I'm working with Fred, and I continued to investigate this issue on our side.

I'm new to kernel debugging and stuff, but I didn't notice anything wrong in 
dokan.
It was just as if Windows didn't send proper IRPs.
Another weirdness : on my computer the recycle bin worked incorrectly, but on 
my VM
there was no recycle bin at all ! I mean, Explorer doesn't show me the "move to
recycle bin" dialog but the "delete" one (as when you press shift+del).
In addition, on my computer, Explorer put my file into the "RECYCLER" dir on 
"D:".
Why not on my dokan drive "M:" ? or at least on "C:" ?
I was wondering why FileSpy replaced "M:" by "\Device\dokan0" in every path, as 
if it
was an alias.
I found the answer with a "subst" command :
  C:\Documents and Settings\rchagot>subst
  M:\: => dokan0
So I guess the Shell/Explorer retrieves the drive letter by getting the first 
letter
of the volume name, and because it's an alias, it gets 'd' (from "dokan0") 
instead of
'M'.
This would explain why it puts files in D:\RECYCLER on my computer (+ another, 
for
testing), but doesn't offer the "move to recycle bin" possibility on my VM 
because
"D:" is a dvd drive, not a hard drive partition.

So I focused on the mount system. I tried to use
GetVolumeNameForVolumeMountPoint/SetVolumeMountPoint in addition to 
DefineDosDevice
(so I had to support IOCTL_MOUNTDEV_QUERY_DEVICE_NAME) but the function failed 
every
time, I had a few leads but I found an easier solution eventually, used in 
other FSDs :
use DefineDosDevice with the DDD_RAW_TARGET_PATH flag, but it requires the NT 
device
name ("\Device\dokan0") instead of the Win32 device name ("\\.\dokan0").
As NTDEVICE_NAME_STRING was not accessible to the mounter, I hacked it (in
DokanControlMount) :
    //wsprintf(deviceName, DOKAN_DEVICE_NAME, DeviceNumber);
    wsprintf(deviceName, L"\\Device\\dokan%u", DeviceNumber);

Then, we have a "Recycled" (FAT32 style) dir on our drive, containing the INFO2 
file
(+ desktop.ini). Deleted files and directory are correctly moved (+ renamed) 
into it.
Undelete works fine too.
Note: This is ok with our FS, but their is still a bug with the mirror sample, I
think it's because we close the handle in the move callback, unfortunately I 
couldn't
fix it quickly and I didn't have the time to dig any further.

By the way, dokan drives are not listed anymore by the subst command.

Well, I hope this could help you to make a clean fix instead of my hack :)
Regards

Original comment by Romain.C...@gmail.com on 22 Feb 2010 at 2:01

[GoogleCodeExporter]

I tried to support GetVolumeNameForVolumeMountPoint, but I couldn't.
Using DDD_RAW_TARGET_PATH flag in DefineDosDevice seems to work file.
I changed the mounter code.
Thanks,

Original comment by asa...@gmail.com on 6 Mar 2010 at 8:21

[GoogleCodeExporter]

The recycle bin seams to work fine in Dokan 0.52
Unless you use DOKAN_OPTION_REMOVABLE but I think that is because of:

"The Recycle Bin only stores files deleted from hard drives, not from removable
media, such as memory cards and floppy disks. It also doesn't store files 
deleted
from network drives."
http://en.wikipedia.org/wiki/Recycle_Bin_%28Windows%29

In Window7-64, recycle bin doesn't seam to work with or without 
DOKAN_OPTION_REMOVABLE.
This might be down to my Dokan app being 32bit and using the 64bit Dokan 
driver, but
I wouldn't expect so... On Win7-64 it doesn't seam even subst drives have 
working
recycle bins.

It was confusing looking into this because of bug that could be Dokan or 
Explorer.

* Create a instance of you drive without the DOKAN_OPTION_REMOVABLE
* Delete a file (checking it has gone to the recycle folder)
* Release the drive.
* Create a instance of you drive with the DOKAN_OPTION_REMOVABLE (same letter)
* Delete a file, and you will see it go to the recycle folder.

If you restart explorer (kill it in task manager and then set it running again 
also
from task manager), and try again, with only running the DOKAN_OPTION_REMOVABLE
version, the files are directly deleted. This only happens in XP, in Win7, I 
never
got the recycler bin working.

Original comment by joe.a.bu...@gmail.com on 25 May 2010 at 3:36