Thanks for your suggestions. I'll consider it.

Hi there,

if you delete something with WinSCP, having the recycle bin option activated (or deleting with Shift+Del), WinSCP effectively does not care about any permissions, which is a major security kludge on systems with a shared /tmp directory like nearly all Unix systems.

Many users are dealing with sensible files, containing e.g. MySQL passwords, for example they're removing an older version of a blog software having its database password stored in a config.inc.php or so. This is fine because the webserver can read the file, and the directory permissions above make sure that nobody else could read it. For example, the home directory of Unix users is typically not readable for any other user except the webserver, so it's not a real problem to let them have their sensible files with mode 0644.

But if they "remove" these files, having the recyle bin option activated, they're simply moved to /tmp directly, without any precautions on its permissions - which means, that a file with mode 0644, that could not be read by other users before, is effectively moved into the public by moving it outside of a protected directory into a publically visible directory.

It would be a good idea to create, for example, a dedicated /tmp/.Trash-username directory per user, with mode 0700 so only the user can read it. That's what practically every modern Linux distribution does with its graphical "recycle bin" functionality. They way WinSCP currently handles such "deletions" seems highly problematic!

Jonas

This request has been added to tracker.

Figures.

Well, I guess this is my vote for a future option to disable the bin functionality altogether.

I believe that WinSCP behaves as Windows Explorer. Then bin is enabled, Del moves to bin, and Shift-Del deletes. When the bin is disabled, it is opposite.

So, you can enable the remote bin to make Shift-Del delete.

There's no option to completely disable the remote bin atm.

A side note: On Windows servers, the recycle bin is user-specific and not at an easily-guessable path, since it requires a call to the well-known-path API. Expecting users to know the recycle bin location and their user SID so they can provide the path to the remote recycle bin (assuming it's even in the default location) seems overly optimistic. If you want to have such a feature, I'd suggest WinSCP attempt to discover this path somehow for the user through well-known-paths. I'm not sure how scp or sftp (much less ftp) would be able to execute arbitrary code as the user on the remote server though. Maybe upload an executable and try an exec request to run it and get the output?

There's no way to detect windows recycle bin path on remote server.
And it wouldn't help though as deleting to recycle bin is not simple as move. There's also some database Windows maintains about deleted files.

I am in the habit of using shift+del to delete files, bypassing the recycle bin. In WinSCP, this behavior does the opposite of what you'd expect, by default moving the file to the recycle bin instead of bypassing it.

When a file is deleted to the recycle bin on a remote server, WinSCP apparently tries to first move the file to /tmp/filename-datestamp.ext. On servers that do not have a writeable /tmp (Windows being one example), this fails.

This behavior seems to occur even if none of the "Recycle bin" checkboxes are selected.

I'm not sure what the intended behavior is, but can there please be an option to completely disable the "Recycle Bin"?

WinSCP 4.1.8 (b415) on WinXP

A side note: On Windows servers, the recycle bin is user-specific and not at an easily-guessable path, since it requires a call to the well-known-path API. Expecting users to know the recycle bin location and their user SID so they can provide the path to the remote recycle bin (assuming it's even in the default location) seems overly optimistic. If you want to have such a feature, I'd suggest WinSCP attempt to discover this path somehow for the user through well-known-paths. I'm not sure how scp or sftp (much less ftp) would be able to execute arbitrary code as the user on the remote server though. Maybe upload an executable and try an exec request to run it and get the output?