Auto-delete

Need help with FileZilla Client? Something does not work as expected? In this forum you may find an answer.

Moderator: Project members

Post Reply
Message
Author
fortissimo
500 Command not understood
Posts: 5
Joined: 2020-05-18 17:51

Auto-delete

#1 Post by fortissimo » 2020-05-19 23:44

Can the FileZilla coders please consider putting in an auto-delete feature that is attached to the successful download or upload of a file? All it would need to do is just validate the the file size is the same on both ends, and if it's the same, delete the source file. This would be SO NICE.

Interface-wise, I would add to the context menu (when someone right-clicks on a selected file or files) an option that says "Move" (in addition to the current Upload and Download options). The first time someone does that, a popup box explains that once the files are done transferring, the source files will be deleted provided the file sizes are the same on both ends. At the bottom of the popup is a checked check box that says, "Always show this warning" which people can uncheck when they're comfortable.

Don't be fooled by those not requesting this feature - the feature would be used all the time by probably most of its users. Sometimes people don't know what they were missing until you show them. (When I'm doing webmaster stuff, I wouldn't use the Move feature, but in almost every other case when I use FileZilla, I'm transferring files, not copying them.)

User avatar
botg
Site Admin
Posts: 32907
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: Auto-delete

#2 Post by botg » 2020-05-20 07:26

There are a couple of challenges making this a dangerous feature:
  • Filesize information is unreliable, wrong values are sometimes shown
  • If a file gets modified mid-transfer but size doesn't change, all that remains would be a local frankencopy that's neither one nor the other version.
  • If using ASCII-type transfers, line ending conversion changes file size
  • With plain FTP, there is no integrity protection, there is no way for the program to know whether the data received is actually the same as the data originally sent.
  • It is possible for multiple remote file names to be collapsed into a single local file name, depending on things like case-folding, locales, unicode normalization, file systems, etc...
  • Pre-existing symbolic and hard links on the target can cause undetectable havok

the feature would be used all the time by probably most of its users.[citation needed]

fortissimo
500 Command not understood
Posts: 5
Joined: 2020-05-18 17:51

Re: Auto-delete

#3 Post by fortissimo » 2020-05-20 08:40

It's not a dangerous feature if you make it an option that the user has to go out of their way to enable in the preferences.

And, all of those things you're afraid of are 1) all very unlikely to happen, and 2) things that your users are intelligent enough to know that if they use this option, it's at their own risk.

To address each of your points:

1) If a file size doesn't match, then the malfunction will be a false negative, not a false positive. In other words, the files won't be deleted. This isn't "dangerous."

2) In my 30 years of FTPing, I don't think I've ever once, ever, modified a file while I was uploading it. If someone is idiotic enough to create frankencopies of files, I'm sorry but for them, even using FileZilla as it currently exists is "dangerous." That person shouldn't even cross the street by themselves.

3) Put a note in the popup saying the feature isn't recommended when the transfer type is set to ASCII. Or grey out the function (disable it) when the mode is set to ASCII. Very few people use that mode anyway, so it's not like it would be a huge sacrifice to not have the feature available when in ASCII mode. Not only that, but the most likely scenario that would lead to someone using ASCII is when they're doing webmaster stuff with HTML, PHP, CSS, JS, etc. files, and one doesn't want to use auto-delete in that scenario anyway since they're editing files locally, transferring them, then refreshing their web browser to see the results on the server.

4) For integrity protection, give your users more credit. Let them proceed at their own risk. Even without this auto-delete feature, I already archive everything I upload with authenticity verification and a 2% recovery record attached to each file. I do this because of past experience with data integrity problems in transferring large files. The first popup people get could also have another sentence tagged on: "Also, please be aware that even wired connections are prone to data integrity errors, especially with larger files. It is strongly recommended that you not use this feature with sensitive data, and/or store your data in an archive utilizing authenticity and/or recovery record before uploading."

5 and 6) Again, extremely rare conditions and actions on the part of the user. Turning away from a feature like this that would be so incredibly useful to so many people just to avoid a couple extremely implausible scenarios just doesn't make any economic sense to me - the pros and cons are not even remotely comparable. You're talking about turning your back on "good" of magnitude 1,000,000 in order to avoid "bad" of magnitude 10.

Oh, and another huge point...

There is no way to verify a file's transfer integrity anyway, with or without auto-delete, other than using file size (and for that, see #1 above). So even if you don't have auto-delete, these "dangers" you list are currently dangers that already come to pass almost as much now as they would with an auto-delete feature. Whether I delete manually or automatically, I'm still deleting under the assumption (but without proof) that it transferred without errors. And if the file is too sensitive, well, that's when "user intelligence" comes into play. In that situation, any user with half a brain will simply not use the "Move" option and will instead use "Upload/Download."

I would imagine Bill Gates could have had a similar conversation about the MS-DOS "move" command around 30 years ago... it wasn't one of the original commands from early versions of DOS. I'm sure there are plenty of freakish things that could happen that would cause "move" to malfunction. Fortunately, Bill Gates recognized that it did probably a billion times more good than it did harm to add the command.

Post Reply