+FTP: no overwrite dialog on rename

[dabazz92]

Total Commander x64, 8.50

When I rename FTP file to something that already exists in the directory, it's overwriting the old file without any warning.

[sqa_wizard]

Yes, this is how FTP works.
FTP server does not raise any error message.
FTP server just overwrites.

[Sob]

But if TC has directory listing with existing file, i.e knows about it, it could check and warn the user. It would be nice feature. Or even better, it could check existence of target file right before the operation using MLST command, to minimize the chance of overwriting file created by something else since directory listing was obtained. Or when the file is moved to some other directory from where TC does not have file list yet.
Asking for overwrites is invaluable feature for local drives, so why not support it on FTP too, when it's technically possible.

[Sir_SiLvA]

2Sob
Because its YOUR job to know what to do...
I wish TC would make me coffee in the morning

[Sob]

Come on, try to be open to new things from time to time. Have a little understanding for those poor limited souls who are not hardcore hackers like yourself. You have nothing to worry about, you would be able to turn these confirmations off the same way you can and I'm sure you did turn off confirmations for local overwrites... or did you really?
Honestly, how can you even use such high-level and so much user-friendly tool like TC? And whole Windows for that matter. Did you ever consider some Unix-like, cmdline-only OS? With file-op commands doing what they are told to, without asking a single question, even if it means total system destruction. With gems like text editor ed that does not bother user with anything like this sissy wysiwyg stuff and you really have to know what you are doing. Now those are the tools for real man!

I think it goes without saying, but just to be sure, don't take this too seriously.

[krasusczak]

Sorry but no chance already ask (http://ghisler.ch/board/viewtopic.php?t=39371) ..

Unfortunately this depends on the server - Unix-based servers often rename files without warning even if there is a file with the same name.

[Sob]

I believe that argument is wrong. FTP protocol does not have any means for warning user about existing file. The result is either success or hard failure. There's no soft failure, i.e. server asking if you are sure to overwrite existing target and following option to say you really do.

It's the same with uploads using STOR command, server doesn't care about already existing file and will happily overwrite it, without saying a single word about it. If FTP client aims to be user-friendly, that's its job to check if target file is already there.

TC does that for uploads, at least when uploading to current directory (if you upload file to "somedir/file.ext" and it's already there, it gets overwritten without asking, which can be considered as bug and could be solved the same way as I propose for rename, by first checking if it's there using MLST).

[ghisler(Author)]

This depends on the server - some servers will return an error, some (mostly Unix-based) will just silently replace the other file.

[Sir_SiLvA]

2Sob
Sorry mate this is the job for a ftp-app as Chris stated more then once TC is not one

[Sob]

2ghisler(Author)
That's right. Permission issues aside, server either supports rename overwrites or not. And handling of both cases is currently not perfect in TC:

a) With overwrites supported, TC just sends rename command and already existing file is silently overwritten.
b) With overwrites not supported (e.g. IIS FTP server always returns error 550), user gets "Rename failed!" without clear indication why.

Checking for previously existing file would help both:

a) It would prevent possible data loss.
b) It would be at least a little more clear why rename failed. Optionally TC could delete the original file and try again, instead of forcing user to do that manually.

Using MLST for that has both advantages and disadvantages. The good thing is that it's very simple and cheap, because it works completely over control connection and does not require establishing a new one. It's no problem to check destinations in other directories, without getting their full listing. The bad thing is that it's still not supported by all servers. But having it as bonus for people with non-outdated servers would be enough, I think. Others will catch up eventually.

2Sir_SiLvA
I partially agree, TC's FTP client is supposed to have basic features. Things like e.g. multi-threaded file transfers is advanced stuff and it's better to get specialized client for that. But checking for existing file before overwriting it is pretty basic stuff.

[petermad]

But checking for existing file before overwriting it is pretty basic stuff.

I agree

[ghisler(Author)]

No it's not. The user can move the file to a different directory, e.g. with
subdir/filename or ../filename.

[petermad]

No it's not. The user can move the file to a different directory, e.g. with
subdir/filename or ../filename.

Yes but that's a special case. At normal copying from one panel to the other TC has the possibility to check for existing files - and I think that is what most users do 90% of the time.

[Sob]

I suggested using MLST for a reason. Any parameter good for RNTO is also good for MLST:

Code: Select all

MLST ../../some/other/dir/index.php
250-Begin
 type=file;size=87;modify=20140228234321; /pub/some/other/dir/index.php
250 End.

Result uses the same format as MLSD listing(*1) and code for parsing that is already in TC. The only problem with it is that it's not available on all servers. But even then, it will help some and hurt none, so that's fine. And petermad is right, for renaming in current directory, no extra data is needed.

(*1) Well, I've seen slight variations. Some servers return filename as you send it, some return absolute path and some strip the path and leave only file name. But in any case it's good enough to verify its existence.

[dabazz92]

A simple user like me don't care about details of FTP specification, it was unexpected that file just got lost IMHO protecting the data from unwise user actions should be the first priority.

Just tried in the FileZilla and it's raising a warning in such case.