In the examples given on various forums, those are the only common factors. Drive being written to formatted with NTFS (although it may be because FAT32 forces smaller file sizes and therefore requires less overhead in the copy routine- I can't confirm whether or not exFAT has it or not). Windows 7 X64 (confirmed that 32-bit doesn't have it) Certain USB controllers (although they can't seem to figure out why it effects some and not others with the same chipset) This is a documented bug that seems to occur specifically in the following scenario: Did you get a moment to look at the Technet thread linked above? There are literally dozens of similar threads that I've found, if not hundreds more documenting the problem that I didn't even get around to reading yet. When copying large files (4GB and up), there seems to be a 20-30% chance of data corruption! And error rate that high is not random. This is specific to Windows 7 圆4 and USB connected drives, and can easily be reproduced on affected systems. I'm aware that there are many places data can be corrupted, but I'm not talking about random data corruption. I'm afraid you may be downplaying the specific problem, however. But if I can't trust Windows' own file copy procedure, how can I trust FFS? I can use TeraCopy to do initial file copies, but I really want to use FFS to do my daily backups. There is no verified "cure" for this copy error. I'm stuck with 7 圆4 for now because of some legacy software that might not play well with W10. But as I understand it, FFS relies on the Windows copy function? So I've just realized that not only am I corrupting large files by copying them from the source to my external working drive, backing them up with FFS to another drive might have been corrupting them even further!Īll I can say is that I'm happy I've never had to restore from my backup folder yet. I use freefilesync to incrementally back up my working files daily to folder on an external drive. Teracopy actually has its own MD5 verification thing, but even without verifying the files, the copies appear to not exhibit the corruption that occurs with Windows file copy. The solution for many people who have noticed, is to avoid using Windows' copy routine, and use something like Teracopy instead. Some googling revealed this is actually an OS bug right under my nose that I wasn't aware of for years! I wonder how many people have this problem and just never noticed? I thought it was hardware related, but changing to a different drive and different cable didn't fix it. I went back and started checking other files, and sure enough I have a whole bunch of random ones that don't match. I realized last night when an MD5 checksum didn't match a file from the original source. There are literally dozens of these threads across the internet. Apparently, Windows 7 圆4 has a major bug that effects many (but not all) computers, when copying to an external USB connected drive. Ok, this is an odd bug that I can't believe I only discovered last night.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |