[enricomauri]

Hi !

FLashFXP is nice, but lacks some important (by my opinion, VITAL) options:

(1) a concrete SYNCHRONIZE command with definable rules

(2) an AUTO RESUME - SMART RESUME feature

(3) a SMART OVERWRITE feature

(4) Multi-part download for big files (like Getright and similar programs). This request speaks for itself but would be a real lifesaver with really huge files.


Let's see everything in details:

1) you surely know other FTP clients has this option, but its usefulness depends on the sets of rules you can define. Without the next two options, it may be senseless.

2) AUTORESUME: when something goes wrong and my download is interrupted for any reason, the file on the PC is incomplete. Now I can use the resume function to resume the download, but what happens if some hours or days passed and the file on the server is changed ? If the new file on the server is equal or bigger size than the previous one, when you are going to resume (because the file you have locally is shorter) you will obtain a completeley useless file (because the first part is from the first version of the remote file and the second is from the new one). Sure, you could trust time/dates, but sometimes they are unreliable. The rule of FXP is "if local file it's shorter, you can resume, overwrite or skip". Too SIMPLE ! You should be able to say something as:

"if I'm downloading a file and it gets interrupted, please just try to download it again xxx times until completed, using an AUTO-RESUME function because it help to avoid a total download of the interrupted file, BUT you should check that the file you are trying to download hasn't changed since you started the download operation (here you could use the server dates, the dimension, XCRC, SFV file checking and so on). "

The necessary information about this operations should be saved in the queue itself, so when you load it back you would know the dimension/date/time of the remote file that you started to download and you can check this info versus the remote site to confirm that the remote file has changed or not. If everything is like in the previous session, you should just retry the download resuming it. Eventually, you could try the SMART-RESUME functionality I describe later on.


SMART-RESUME: Let's suppose another situation: you have a local file which is shorter than remote file and you suspect it could have been cut off during a transfer. Dates are the same or not, it doesn't matter or you can't trust them. You would try to resume the file, but how can you be sure that in the server there is really the very same file that you started to download ? A possible solution would be to download the first and last KBytes of the remote file (not ALL the file, just some leading and trailing KBytes)
and compare them to the corresponding part of the local file itself. If they compare, bingo ! Probably you are safe to resume it (at least, you should try to). I do not say that it's a perfect solution, but it would help a lot in the situation described if you handle a lot of big files via FTP. For sure, if the checks fail you are completely sure that you have to redownload the entire file (full overwrite). An automation in this sense would be a great addition to FlashFXP. It's useful too if something went wrong during the saving of the last chunk of the local file, because you could immediately spot the difference and decide what to do (ideally, the FTP client could be asked to cut the last KBytes of the file, the ones that tipically get trashed are 4/8 KBytes, and then try again to check against the remote file itself).



3) SMART OVERWRITE

Then, imagine another possible and similar situation (specular to the SMART-RESUME one): you have downloaded some medium/big files (let's say files of 10 MBytes or more) in the past days and you want to be sure they are the same that resides on the remote server. You see different dates on the remote files, but size is the same: what are you going to do ? Well, especially if the files are ZIPs or other types of archive (but it may work on a lot of other file types too, it depends...) you could just download the first and last 32 Kbytes of the remote file to check them against the same parts on the local file. If the checks fail, again you are sure that the file must be fully redownloaded (and cannot be resumed!). Tipically, the different files takes place in the queue with the flag "OVERWRITE THE LOCAL FILE".



4) well, Multi-part downloads are an old feature for other FTP clients, but sometime the are not working well. Maybe FlashFXP people can do it better? I hope !



That's all folks !
Should you need some help in defining the possible user interface for this modifications, I'm willing to help.

Thanks a lot for your time and attention,

EM