Can't delete subfolders of symlinks in a subst-ed folder

Help & Support
1

To be clear, this behavior occurs also in Explorer, but not in some other file browsers, like Total Commander or NexusFile.

I have the following scenario:

  • I have a C:\Foo folder which I subst-ed for easier access as the drive X:
  • It has a symlinked folder SymlinkFolder (let's say to D:\CatFolder, doesn't matter here).
  • I navigate to X:\SymlinkFolder and press the delete button on a subfolder, SomeSubfolder.
  • The problem: instead of deletion, I get a permission error "You'll need to provide administrator permissions to delete this folder" popup (If I click (Admin) continue, it gives another permission error). I get this permission error even if DOpus explorer is elevated/launched as admin.

Notes:

  • What's affected: symlinks to drives for other devices, symlinks to network locations. So eg. a symlink to C:\Abc is not affected by above
  • when I do the same on un-substed folder - so C:\Foo\SymlinkFolder\SomeSubfolder, the deletion occurs without problem.
  • when I do the same in (un-elevated) terminal as rmdir SomeSubfolder, it works without a problem
  • within DOpus, I can rename and even move the said folder, un-elevated with no issues as well. So eg. I can create a folder, then move and rename, only not delete it.
  • This only affects directories in the root of of a symlink, not any of their subfolders.

I wish I'd knew why this happens. And why does it work on other file browsers? Would it be possible to change the delete behaviour in DOpus in a way that this could work?

2

That sounds like the Recycle Bin is displaying that, as it's not something Opus itself would display.

My guess is that you're deleting to the Recycle Bin in Opus and Explorer but not in the other programs you tested, which would explain the difference between programs.

What the Recycle Bin does is more or less down to Windows. Opus can bypass the Recycle Bin if you wish, but then obviously the files can't be undeleted (or at least not as easily).

3

Well, thanks, it really does seem to be the problem... On shift-delete the folder is deleted without permission error. So the problem is that a system process tries to move the folder to recycle bin, and fails because it can't do unelevated? It would be cool to somehow predict if this would happen and come up with a better warning.

4

I'm having the same issue but under different circumstances. I have a folder that is left over after a program update. Sometimes the folder will delete with no issues but sometimes I get the "You'll need to provide administrator permissions to delete this folder" popup. I have not tried Shift-Delete but if I go into the folder and select all the folders & files they will delete with no error and when I go back to the folder which is now empty the folder will delete with no errors.

5

We have no control over what the Recycle Bin does, and the message and elevation prompt from from it, i.e. from Windows. Opus's only involvement is to ask the Recycle Bin API to delete what you selected, after which Opus is not really in the picture (other than things like antivirus might react differently to the Recycle Bin being used in one process vs another).

You'll presumably see the same thing in File Explorer.

It means there either really was an issue deleting the folder (possibly a temporary one) or there's a bug in Windows. Either way, we can't change that.

It often just means something else is still using the files, which blocks them from being deleted.

Program Files / updates usually do require admin rights to delete them, too.

6

I have not tried Shift-Delete but if I go into the folder and select all the folders & files they will delete with no error and when I go back to the folder which is now empty the folder will delete with no errors.

This is the same for me, it only happens on one level - and I think this has to do with how Windows detects to which drive('s recycle bin) that file belongs. Within the folder, it might be detected differently (symlink is resolved, or it is properly detected that it's a network location and not local)

The only way DO could counter these if it would separately try to guess if Recycle Bin API can resolve the above, but that would be horribly dirty and results would need to adapt behaviour differences between Windows builds.

1 Like