to test the file integrity, would require a test at the end of the file. the best solution would be during the rollback, however the corruption could of occured when the connection was lost and the rest of the file might be ok. so if the integrity check is done on the data that is going to be replaced, if the data doesn't match and we overwrite the data the user could end up loosing GBs of data that was in fact flawless.
If we were to test in any other part of the file it would require starting/stopping and then resuming from the end of file, which could lead to another problems.
Future versions of FlashFXP will support XCRC which will allow us to validate the download to insure it's identical to the copy on the ftp server.
Starting with build 1070 the "Auto-Save on change" referring to the auto-generated queue file, saves are now spaced out to eliminate performance lost when transferring lots of small files. The original method of always saving after a transfer was probably not the best way to do this, simply because saving so often can result in the queue file being corrupted if windows crashes/blue screens at the exact same time. Which is one of the reasons no new option was made to allow saving after every transfer.
|