Total Commander

On current time ftp clients Move acting as Copy and we need perform 2 actions: copy and delete instead just Move.

Lomik_XP wrote:On current time ftp clients Move acting as Copy and we need perform 2 actions: copy and delete instead just Move.

Christian has explainded the reason and I guess he will not change his mind.

How do you imagine moving from FTP to local disk in one operation? There is no move operation between remote host and local disk, you can only copy file first and delete it...

MVV wrote:How do you imagine moving from FTP to local disk in one operation? There is no move operation between remote host and local disk, you can only copy file first and delete it...

User use two operations, user use one operation what is more faster?
I mean, I use move file/folder, machine doing copy and remove for me file/folder. Its easy and saves time.

Lomik_XP wrote:

MVV wrote:How do you imagine moving from FTP to local disk in one operation? There is no move operation between remote host and local disk, you can only copy file first and delete it...

User use two operations, user use one operation what is more faster?
I mean, I use move file/folder, machine doing copy and remove for me file/folder. Its easy and saves time.

But as Christian says, what if the transfer was not successfull ?
Then you would not have any file left.

I agree with Horst Epp here.

The ftp protocol does not have any form of data integrity protection (or verify mechanism) to ensure that the client downloaded the file without data errors (this also applies to uploads, btw). Thus an (atomic/automatic) Move operation would be a rather risky operation (some would say such are the adventures spicing up your life ), as neither the ftp client nor the ftp server can tell whether the data was transferred successfully and error-free.

(Side note: Several years ago, there was an IETF draft to specify/standardize an FTP command for file checksums/hashes which would address the problem of lacking integrity checks/protection. Unfortunately, this did not lead to anything, and the responsible IETF workgroup ceased any activity around 2013, as far as i can tell...)

Horst.Epp wrote:...

elgonzo wrote:...

Are you sure?
The topic is move from FTP to local.
When you are copy files from ftp you CAN check it integrity and say it loaded or not, the ftp protocol does not play any role here.

Lomik_XP wrote:Are you sure?
The topic is move from FTP to local.
When you are copy files from ftp you CAN check it integrity and say it loaded or not, the ftp protocol does not play any role here.

Yes, YOU can - AFTER transferring the file. The ftp client cannot do, as it does not know anything about the correct, intended(!) content of the files transferred. If YOU find out that the transferred file has data errors after an "ftp move", what are you gonna do...? I mean, the file isn't anymore on the server after an "ftp move", so retrying the download is not an option...

I get what you are trying to do, but that is best left to you. If you download specific file types which you know how to test/verify for correctness, you could write some "FTP move script" that downloads+verify+deletes files according to the specific file types you have to download. If done right, it should then even be possible to bind the script to a "FTP move" button in TC's button bar (just a thought...)

Asking for a general "FTP move" feature that in the very best case is only feasible for a rather limited number of file formats would be a bit silly, if you ask me. (Think for a moment about the sheer number of file formats out there. Some are not open and to use them would require license payments , others are poorly documented with flavors specific to particular application versions, and then there are so, so many which do not even incorporate metadata needed for integrity checks...)

elgonzo wrote:...

Ok, i get it. But its exactly ftp client problem about copy and check integrity. And at least we can check size of file and when delete (corrupted bits are mystic problem and are not considered)

Lomik_XP wrote:Ok, i get it. But its exactly ftp client problem about copy and check integrity. And at least we can check size of file and when delete (corrupted bits are mystic problem and are not considered)

As long as the file size is okay you do not seem to be concerned about the occurrence of data corruption. That's fine as it is your decision/view which only applies to you and doesn't affect others.

But it is not really a strong argument for a feature that, let's be frank, is not just about what you deem to be an acceptable risk. See it that way: Data corruption during FTP transfers is a bit like car crashes. Just because you never were involved in a car accident or just got some minor scratches on the bumper doesn't mean that car crashes are a rare and/or harmless event. You cannot generalize only from your own limited experience. And that's where your argument really dies...

Lomik_XP wrote:But its exactly ftp client problem about copy and check integrity.

There is no means of integrity check in the File Transfer Protocol. It's an ancient protocol developed in a time when nobody thought of security, integrity (like checksums) or any other comforts we have in other protocols today. Comparing the file sizes is not enough to be able to tell whether or not a file has been transferred correctly. One swapped byte, and your file might be useless. So I agree with elgonzo.

Regards
Dalai