When renaming/moving remotely, ask for confirmation if target already exists

[James]

When moving a file up a level by drag and dropping it over the '...' (at the top of the folder) the file will be copied to the parent folder. If a file already exists then it will be overwritten without confirmation.
This has made me loose progress on my index.php accidentally several times and I know it will happen again.
It is easy to accidentally drag and drop a file (you will be surprised!) so it should ask 'file xyz already exists, would you like to overwrite?'
This is critical because this behavior should NOT happen and WILL cause others hours of (re-)work like it did for me.

[Alexander Schuch]

This is somewhat related to ticket:2191. However, the difference is that even if drag'n'drop is actively desired, an overwrite confirmation should be shown.

Just from a technical point of view, this probably cannot be implemented in a 100% safe way. FileZilla might not know what files are present in another directory, as that directory might not yet be loaded into the cache. And even if it is, the cache might be outdated. And even if it is not, there might be a race condition between check and rename.

The problem probably boils down to the fact that a "move" or "rename" FTP command simply overwrites possibly present files without asking. This probably is a limitation of the FTP protocol.

[James]

Thank you for your response.
After reading this through I understand and would like to suggest the following instead;

a notification to confirm that you would like to move the file. Hitting enter to confirm is easy and if you did it by mistake then it is also easy to cancel it!

[Arnaud Chéritat]

Old topic but... I just destroyed an index.php because when I double clicked a folder my hand jittered by a fraction of a millimeter and a drag-and-drop action was detected instead of a double click. As a result a copy instruction was sent, copying index.php to a sub-folder where index.php already is.

I don't agree that querying the target folder file lists just before the copy instruction is a problem: when copying from local to remote, this is probably what is done anyway. In other words: why copying from local to remote can query remote destination folder file list but copying from remote to remote should not query remote destination folder file list?