TR Forums

1. When files are deleted by remote, delete locally to the Recycle Bin.
2. That supports not only file "modified" time, but also "created".
I don't think that's standard for SFTP, but maybe there are extensions? (Though would need also client support, I don't think WinSCP supports it).

Bitvise's SSH Server doesn't provide either.

Alternatively, any recommended light FTP/S server/clients that can do it?

Recycle bin stuff is not part of SFTP at all. You could script a command to "delete" a file from the server as standard file move command that happens to have a target as your local recycle bin folder which effectively "deletes" the file with the local copy ending up in your recycle bin.

File creation times are part of the filesystem itself and many UNIX filesystems (where SFTP is primarily used) don't do file creation times, although Linux is starting to implement that metadata as an option*.
I'm not sure that SFTP is configured to show this information even though it exists assuming an underlying NTFS file system.


* See the relatively new statx system call: http://man7.org/linux/man-pages/man2/statx.2.html Of course, the underlying file system has to support the metadata in the first place and your software has to be wired up to use and interpret the output of this system call.

IIRC Xlight can do that, but features like SFTP have to be paid for.

> feature "Delete file and directory to Windows recycle bin" is selected.

Also AFAIK Filezilla Server under Windows uses SHFileOperation so the "delete" should function like a native Windows delete, though don't take my word for this without testing it first.
Edit: Googled and this is wrong.

This might? At least it supports advanced directory listings, whatever that means. A vendor makes us use it at work but I don’t actually use it myself.

http://www.coreftp.com

I'll try them (cheap sites notwithstanding ), thanks.

Recycle Bin doesn't really need SFTP-level support, it can be a server settings that's transparent to the client.

chuckula, did you have a specific server in mind for scripting?
Move to Recycle Bin directory won't create the shell metadata, but I guess it should be possible to trigger a shell-delete.

meerkt wrote:

I'll try them (cheap sites notwithstanding ), thanks.

Recycle Bin doesn't really need SFTP-level support, it can be a server settings that's transparent to the client.

chuckula, did you have a specific server in mind for scripting?
Move to Recycle Bin directory won't create the shell metadata, but I guess it should be possible to trigger a shell-delete.

When it comes to deleting from the server where the files end up in the recycle bin of the client [or even the recycle bin of the server for that matter], the main piece of software I would think of would actually be the SFTP client and not the SFTP server. It's the client's job to issue the commands to the server to perform the basic file operations that get the job done. When it comes to recycling a complex directory structure, you'd use the same general SFTP commands that are used for a recursive file move operation, with the exception being that the destination of the move happens to be the Recycle Bin instead of a normal directory. I'm still not quite sure if you want to delete files from a server where they end up in the recycle bin of the server or instead in the recycle bin of the client but both operations should be possible if the client is configured properly.

I don't know how "transparent" this operation would be though. For example, if you just expect to issue the standard delete ("rm" in UNIX parlance) command and have files end up in the correct recycling bin, I'm not aware of any software that does that by default. If you can setup the client to delete by actually moving the files (including more complex directory structures) to proper target in the recycle bin, then that might do the job.

Here's the closest thing I've found that might be close to what you want where the client (WinSCP in this case) "deletes" files on a server by copying them to a predetermined directory [on the server in this case] that you could re-target to be the standard Windows recycle bin: https://winscp.net/eng/docs/ui_login_recycle_bin

Hopefully this points you in the right direction, but I don't know if it does everything you want.

I want a delete on the server to use the server Recycle Bin, of course, and be fully handled by the server. No point in being at the mercy of the client.

Regarding file move, didn't know that option exists in WinSCP, thanks. Though I don't see a simple way to turn that into the equivalent of Windows' delete-to-RB. Moving files into the RB directory won't store their pre-move location, nor their deletion time, and they won't show up in the Recycle Bin GUI.

meerkt wrote:

I want a delete on the server to use the server Recycle Bin, of course, and be fully handled by the server. No point in being at the mercy of the client.

Regarding file move, didn't know that option exists in WinSCP, thanks. Though I don't see a simple way to turn that into the equivalent of Windows' delete-to-RB. Moving files into the RB directory won't store their pre-move location, nor their deletion time, and they won't show up in the Recycle Bin GUI.

Yes, you are now talking about the more intricate properties of the Recycle Bin. The SFTP protocol (at least the "pure" version of it) doesn't handle any of that as far as I know. If you are looking for a Windows-specific solution I'd maybe investigate something other than an SFTP solution since these solutions are first and foremost for Unix [or more accurately, POSIX] systems and Windows-specific functionality is not going to be part of the package.

That's not to say there aren't solutions available, just not what you would call an SFTP server.

It sounds like you're looking for a cheap way to have SFTP with versioning? In the past few months AWS released a fully managed SFTP service for S3 which sounds like it could be an alternative.

https://aws.amazon.com/blogs/aws/new-aw ... amazon-s3/

Of course that violates the "windows only" requirement, but without knowing anything about your users or environment I'd say it's probably easier to change the backend storage setup than to force all your users to abandon their FTP clients in favor of something else. Usually I'm part of the "FTP must die" camp, but.... yeah that's easier said than done sometimes.

You could also just replicate to S3(or wherever) and keep the FTP server at stock if moving everything is not in the cards.