File Corruption from Power Cut - Suggestions
Posted: 2021-03-23 09:28
I was transferring a 40 GB .7z file from one computer to another using FZ server and client, and there was a momentary power cut, and the computer had to be restarted. I 'resume'd the download in FZ and at the end did an MD5 and the final file checksum did not match the original. I'm sure this was caused by the power cut as none of the other files (about 1 TB) have had a problem. As the connection here is slow enough, it will take a good while to retransfer.
So my question is this - is the Resume function implemented ideally in such circumstances? for example, perhaps there should be an option of 'Resume after abrupt computer shutoff' (or FZ can somehow keep track of tidy closures and so assume any others were untidy) which, based on disk write cache size (supplied, likely or max) and any other relevant factors, filezilla would start transferring somewhat *earlier* than the existing file size so it redid a suitable extent of bytes before the end of the existing partial transfer before proceeding with the entirely new bytes extending the partial one...
As it is a 7z file, composed of many entries, I probably can fix it by extracting the extractable files, refretching the missing ones as a 7z and if needed MD5-ing all the files in source and destination although I think 7z will naturally have covered that with its own processes so long as I ensure the resulting files match as a list. However to have FZ cover these abrupt failures in an improved way I think would be the ideal as it would make that unnecessary and deal with files that that won't work with...
David
So my question is this - is the Resume function implemented ideally in such circumstances? for example, perhaps there should be an option of 'Resume after abrupt computer shutoff' (or FZ can somehow keep track of tidy closures and so assume any others were untidy) which, based on disk write cache size (supplied, likely or max) and any other relevant factors, filezilla would start transferring somewhat *earlier* than the existing file size so it redid a suitable extent of bytes before the end of the existing partial transfer before proceeding with the entirely new bytes extending the partial one...
As it is a 7z file, composed of many entries, I probably can fix it by extracting the extractable files, refretching the missing ones as a 7z and if needed MD5-ing all the files in source and destination although I think 7z will naturally have covered that with its own processes so long as I ensure the resulting files match as a list. However to have FZ cover these abrupt failures in an improved way I think would be the ideal as it would make that unnecessary and deal with files that that won't work with...
David