by chrisjj » Sun Feb 21, 2010 1:37 pm
I am guessing - only guessing - that an MM crash during sync can leave corrupt the currently copying file on the device yet record that copying was completed.
I say this because it is the most likely explanation I see for an ongoing issue here. Since approx a year ago when I started using MM auto-sync to a HD folder via d_USBMass1.DLL and a SUBST drive, a period during which I have frequent MM crashes, occasionally I have found an output file to be corrupt - past some point all bytes are zero, even though name, size, and date are correct. Fair enough... except that a repeat sync does not remedy the corruption, as if MM were falsely recording that the file was copied completely.
It should take only a few moment for the Devs to check this is the code. It would be nice to get it fixed.
Tracked at
http://www.ventismedia.com/mantis/view.php?id=6278
Workaround: Check integrity of output files somehow, delete corrupt ones, resync.
I am guessing - only guessing - that an MM crash during sync can leave corrupt the currently copying file on the device yet record that copying was completed.
I say this because it is the most likely explanation I see for an ongoing issue here. Since approx a year ago when I started using MM auto-sync to a HD folder via d_USBMass1.DLL and a SUBST drive, a period during which I have frequent MM crashes, occasionally I have found an output file to be corrupt - past some point all bytes are zero, even though name, size, and date are correct. Fair enough... except that a repeat sync does not remedy the corruption, as if MM were falsely recording that the file was copied completely.
It should take only a few moment for the Devs to check this is the code. It would be nice to get it fixed.
Tracked at http://www.ventismedia.com/mantis/view.php?id=6278
Workaround: Check integrity of output files somehow, delete corrupt ones, resync.