up vote 6 down vote favorite
share [g+] share [fb]

Related to this question but not identical.

Scenario:

C:\Folder\Symlink\ is a symlink pointing to E:\Folder\Folder\Target\

Problem:

Deleting a file through C:\Folder\Symlink\* bypasses the Recycle Bin, even though both C: and E: have the Recycle Bin enabled. This only seems to happen with cross-volume symlinks.

Example:

  1. Using the above symlink structure, create a file C:\Folder\Symlink\somefile.txt
  2. Delete C:\Folder\Symlink\somefile.txt by using either the Delete key or right-click > Delete.
  3. The prompt comes up for immediate deletion, instead of offering to send the file to the Recycle Bin.

Question:

Can anyone else reproduce this, and is there a fix?

Update:

Did some more digging and was able to further isolate the issue.

In the list below, Denied specifies a folder that has access permissions revoked for the current user. All other folders have Full Control. Permissions are not inherited. Each folder has explicit permissions.

  • C:\Folder\Symlink\ => E:\Denied\Denied\Target\ = Recycle Bin? NO
  • C:\Folder\Symlink\ => E:\Allowed\Denied\Target\ = Recycle Bin? YES
  • C:\Folder\Symlink\ => E:\Allowed\Denied\Denied\Target\ = Recycle Bin? NO
  • C:\Folder\Symlink\ => E:\Allowed\Allowed\Denied\Target\ = Recycle Bin? YES
  • C:\Folder\Symlink\ => E:\Denied\Allowed\Denied\Target\ = Recycle Bin? YES
  • C:\Folder\Symlink\ => E:\Denied\Denied\Allowed\Target\ = Recycle Bin? NO
  • C:\Folder\Symlink\ => E:\Denied\Denied\Denied\Target\ = Recycle Bin? NO

Adding at least two Denied folders in a row introduces this issue. It seems the shell is not able to see through through more than one consecutive unreadable folder?

link|improve this question
83% accept rate
2  
I think this behavior is intrinsic to the symlink. After all, which recycle bin should it go to? – soandos Dec 20 '11 at 17:05
1  
@soandos - Presumably, the physical volume on which it is located. – Unsigned Dec 20 '11 at 17:57
Why? That would defeat the purpose of a symlink. – soandos Dec 20 '11 at 17:57
@soandos - The item being deleted is not a symlink. It's a file being accessed through a symlinked directory. How does having the file sent to it's host volume's Recycle Bin defeat the purpose of symlinks? – Unsigned Dec 20 '11 at 18:13
Read the answer. That is what I mean. The purpose of a symlink is that it does not matter at all where the file "actually" is. – soandos Dec 20 '11 at 18:15
show 5 more comments
feedback

2 Answers

up vote 1 down vote

I have a similar setup, but I get the move to recycling bin prompt.

Cross volume link.

Symblink

Hit Delete

Delete

link|improve this answer
I assume to the physical volume's Recycle Bin? Now if I could only figure out why my machine doesn't want to do that... – Unsigned Dec 20 '11 at 18:19
Umm, I can't tell which one it goes to :) The recycle bin is aggregated for local volumes. I'll have to get back with you on that. – surfasb Dec 20 '11 at 18:24
Yeah, it shows up in the target's volume location (C in my case). – surfasb Dec 20 '11 at 18:28
The two dialogs you show do not seem to have any relation to each other. Could you clarify? – kreemoweet Dec 20 '11 at 18:45
@kreemoweet: I followed the OP's instructions. I posted these pics to show I got a different result. – surfasb Dec 20 '11 at 18:52
show 3 more comments
feedback
up vote 0 down vote

Sorry, nope, no fix. It's "by-design". If the delete dialog cannot determine the physical location of the file, the permanent delete dialog is shown instead. With a symlink, the physical location of the file is "indeterminate" at best... so no-chance for the move-to-recycle bin option.

link|improve this answer
Huh? If the physical location were "indeterminate", symlinks would be useless, no? – kreemoweet Dec 20 '11 at 18:47
Not at all. The physical location is not the same as the path. The same problem exists on network paths via UNC... or web-based files... etc. If the delete dialog isn't provided physical location to the file (i.e. c:\filename), it's treated as if it came from somewhere else. Symlinks aren't the same as hard links. – TheCompWiz Dec 20 '11 at 18:51
And yet, your answer is wrong. Normally the shell can tell the physical location of the file. The issue seems to be permissions related. Please refer to the updated details in the question. – Unsigned Dec 21 '11 at 3:44
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.