Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)


Topic review


Re: Files below directory with 'Permission Denied' are still deleted if the file permission allows

WinSCP first recurses to delete contained files. And only after that, it tries to delete the folder (and fails). You cannot do it the other way around, obviously. So it's an expected behavior.

Sorry, should have mentioned version: WinSCP 5.13.1 (Build 8265)

Should have also mentioned that this matches the
rm -rf
behaviour in Linux (toplevel remains, contents deleted), just wanted to confirm this is how it is expected to behave in the WinSCP UI.

Files below directory with 'Permission Denied' are still deleted if the file permission allows

This may sound like a strange use case, but I can explain in more detail if required. I have found the following behaviour in WinSCP and wanted to confirm that it was expected.

When there is a parent directory that a user has write access to (eg. through group permission) and that user has write access to files in that directory, when the parent directory is deleted in WinSCP, WinSCP displays the 'Permission Denied' for the deletion of the parent directory but still recurses the directory and deletes any files the user has the ability to delete below the directory.

To reproduce, create the following structure on a Linux host:

mkdir toplevel

chmod 2770 toplevel
chown root:mygroup toplevel
touch toplevel/myfile
chmod 664 toplevel/myfile
chown root:mygroup toplevel/myfile

When you WinSCP as a user that is a member of 'mygroup' that isn't root, select the 'toplevel' directory and delete. The result is a 'Permission Denied' error for the 'toplevel' directory, but the 'myfile' file is still deleted. Essentially, it recurses below 'toplevel' because it has read access, where I would have expected it to stop recursing if it can't delete the 'toplevel' directory. Is this expected behaviour?