Don't overwrite file until transfer is complete

[dirTdogE]

While uploading a file, the file which is being overwritten is done so in real-time rather than waiting until the transfer has finished. In other words, if it takes you 60 seconds to upload the new file, the old file is unusable for a period of 60 seconds. This is a major problem if the file you are overwriting, for example, is a server script which is accessed hundreds or thousands of times per minute. Of course, it's an even bigger problem if the connection is interrupted mid-transfer.

From the client end, I suggest a feature which allows uploading filename.ext as filename.ext.uploading (or something), then deleting the original file and renaming the new copy once the transfer is complete. This should be more seamless than the existing practice.

Of course, this should ideally be handled on the server side automatically, but I'm requesting this for the client because I am actually not using a FileZilla server on our (Linux) machines. It would be awesome if such a feature were implemented in both your client and server.

Thanks for taking my request into consideration, and thanks for a great piece of software!

[Tim Kosse]

One problem is that not all servers support or allow file renaming.

[dirTdogE]

Replying to codesquid:

One problem is that not all servers support or allow file renaming.

Hmm ...

One potential solution could be to test this with a tiny dummy file before beginning the real transfer. This would allow to fall back to the currently standard behavior. Of course, this would be quite sub-optimal, as it would introduce latency to every upload for every user ...

Another potential solution would be to immediately begin the transfer as described in the feature request, then, if a renaming error occurs, you would have to delete the uploaded file (e.g. "filename.ext.uploading"), and begin the transfer again, but falling back to the currently standard behavior. This is obviously much more severely sub-optimal, but I imagine that it would not effect very many users (or are there many servers that don't support renaming? (Also, how do you handle this (if at all) with regards to the "Rename" entry in the context menu?)) ...

One last potential solution (which I think is the best compromise of the three) would be to add a server setting to Site Manager for whether or not renaming is supported (or for whether or not to use the feature I have described above for that particular server).

[Tim Kosse]

One potential solution could be to test this with a tiny dummy file before beginning the real transfer.

In case of those ugly, unlistable, write-only upload directories the result would be countless tiny dummy files uploaded by every single user. Not a viable solution.

Another potential solution would be to immediately begin the transfer as described in the feature request, then, if a renaming error occurs, you would have to delete the uploaded file (e.g. "filename.ext.uploading"), and begin the transfer again, but falling back to the currently standard behavior.

If server doesn't allow rename, why should it allow delete?

One last potential solution (which I think is the best compromise of the three) would be to add a server setting to Site Manager for whether or not renaming is supported (or for whether or not to use the feature I have described above for that particular server).

That would work.