Hash-Based Resume

When a file exists on the server you are uploading to, and the hash doesn't match, and none of the assertions match, it overwrites the file. (Even when the file is an incomplete form of the file you are uploading [Meaning, resumable])

On some FTP server hash-checks are possible to see if two files are the same, as FTP uses to do so.

It would be very usefull to use that hash of the file and compair it two the hash of the first X bytes of the file you are trying to upload. (X would be the length of the already existing file) If they were to match, we know that it can be resumed.

This would keep you from overwriting files that can easily be resumed when on a queue.

That has been implemented almost a year ago already.

Regards,
SmartFTP

I have checked this numerous times, and i cannot find how this is so.

I partially uploaded a few different files to my server.

I then queued them again on smart FTP, and instead of resuming them, it overwrote them.

The log stated that it checked the hash of the files and that they did not match. But these checks were for the whole file, not a partial version of the one being uploaded. If this had been done, the hashes would have matched, and the file would have resumed.

Either i am doing something wrong, or the function has not been implemented, or simply isn't functioning correctly.

Again, i have done similar tests numerous times to check this functionality, and they have all proven negative.

Is it possible you are referring to a different function?

Cheers,
Emu-Xperts

I can pretty much assure you that there is nothing wrong with the hash based resume. If you believe otherwise please post a proper bug report. If you need technical support in understanding how it works the premium support team can provide licensed users with a detailed answer.

Regards,
SmartFTP

Well, my mistake.

Appologies for being a bother.