Windows 7 x64 seems to have a long-standing and serious bug in the USB disk I/O system. Few users notice this unless the file has some sort of built-in error detection capabilities. After getting quite a few corrupted files on my perfectly working USB disks and flash drives over the years, I searched various forums for similar reports. Such Win7 problems go back to day one for Win7, for 64-bit installations. It does not seem to depend on the h/w at all, and it is not a USB3 issue. Here's a summary. 1. Corruption occurs when writing to a USB storage device, but not when reading from a device. 2. The corruption is usually not reproducible. It is quite flaky and random. I suspect this is a software/hardware timing issue with buffers, rather than a logical error in the Win7 operating system. 3. I usually store offline files in archives (zip, 7z, etc) or compute checksums for newly written large files. This is how I became aware of the problem. Corrupted files may be of any size. 4. The problem is not related to any updates or service packs. Seems to be confined to Win7 x64. 5. As shown in the next post, the error is an absence data in whole sectors of the o/p file. 6. One user has reported that switching the USB caching policy from write-thu (quick disconnect) to write (performance) will cure the problem. ======================= A specific example I wrote a 1GB file from my laptop (Ausus EM642G) to a 750GB WD USB disk. The disk was new and fully zeroed (0x00 in every byte) before formatting. A SHA1 check showed that the new file on the external disk was not the same as the original one on the C-drive desktop. Using unix tools the following were results found. 1. The new file was the correct length. The first 555MB (55% of 1GB) was identical to the original file. There were then 40 consective sectors in the corrupt file, that had zeros in them. It was exactly 40 of 512byte sectors. The next few megabytes were correct. Futher errors were all in exact groups of 512byte sectors. 2. The zero sectors were mostly likely due to the free space being all zeroed. The problem was that no data at all was written to them, rather than bad data. 3. When pasting in Win7 , the progress bar went to about the 50% mark instantly, and then filled up to the 100% mark at normal speed. 4. Looks like a buffer flushing problem. There are multiple s/w buffers for a single i/o opertion. Disk space is allocated correctly, but the buffers never get written. -------------------------- This is a very serious problem, and MS needs to admit it, and to fix it. The average user is mostly unaware of this corruption. When they do find this problem, the USB device is always blamed, and junked.
.. because corruption is impossible, when only reading: by definition. Exactly, even as demonstrated in your rant (hihi) post here: there are (way) too many variables to even begin to understand where the *problem* may lie. P.S. Barely ever would I note such discrepancies and even then it can be *fixed* by re-archiving the file - in a different way, perhaps - so it's not a big deal. ;$ Read: chit happens =)
I've never had any USB problems, but I've always made this change to my devices by default. I don't have time to waste waiting around for files to transfer. It's slow enough even with the performance mode. I currently have 5-6 external USB hard drives connected at all times and use various flash drives for stuff as needed. So my USB ports get used, heavily. I also use TeraCopy most of the time.
Doing this has been a standard practice of mine since I first started using USB storage devices ... it just made sense. And in many cases, I make the file system NTFS but that's another story altogether. Currently we have only one x64 Windows 7 machine but the USB storage devices that get connected to it from time to time are numerous. We've had absolutely no problems with corruption. Not saying it doesn't happen, it's just our experience over the past four years or so has been wholly positive. Considering the number of x64 installations out there, and the total number of reported problems you've commented on, the problem might be less significant than you believe. I've learned over the years there will always be problems with everything, once in a row does not set a trend and serious computer problems generally get spread loudly both far and wide.
[nimd4] >because corruption is impossible, when only reading: by definition. So a CRC read error from reading a DVD is impossible. The Reed-Solomon algorithm is clearly a waste of time. You'd better write a paper and submit to ACM. The next Turing Medal is all YOURS! [JellyBelly] >I also use TeraCopy most of the time Indeed Teracopy works, as noted by users who have tried to work around the issue. ---------------- I thought MDL may be an improvement over Toms H/W, but apparently not.
Why? Because someone disagreed with you? Because your very first post didn't get the attention you thought it deserved? What kind of worthless forum would it be if everybody agreed perfectly with everybody else? On that utopian forum there would be no discussion, no divergent opinions, no solutions and no interest. The very raison d'être for a forum is the free expression of divergent opinions, options, solutions and comments. And that necessarily means opinions will differ, not all suggested solutions will work and that a solution might not ever be found. Forums are for free discussion. Sometimes there are many solutions offered and sometimes there are few; sometimes there are just comments. But one thing is for sure, if I felt MDL was substandard (after even only one post) I'd go back to whatever forum I found to be better. Maybe you should consider that.
Interesting; guess I know what I'm enabling on my 7 installs now. I always safely remove external drives anyway, and the extra performance will be nice.
You might be interested in knowing that there is no actual performance increase. Changing the caching policy, does not effect the write speed of the device, it just allows the operation to appear to finish before it actually has. In the simplest sense, your file is read from its original location, into memory, at which time you will see the progress bar reach 100%. The actual data will still need to be written to the disk, and removing the disk without flushing write cache (writing everything to disk from memory) will result it corrupt/damaged/missing files. If you do not use a journaling file system (NTFS, EXT4, HFS, etc), and use EXT2, FAT32, exFAT, etc you can experience full disk corruption even. Well put.