Bogus file corruption issues with TortoiseSVN on Windows 7 64-bit

Last Thursday I encountered a strange and frustrating issue. There are a wealth of blog entries out there about this, for anyone who bothers to search, but I am going to summarize it regardless. I myself didn't google it until after it happened to a coworker as well - at that point I knew something was up.

I've used Windows 7 64-bit with Microsoft Security Essentials at work for over a year now. For the last 4 months, I've had an Intel SSD in my workstation at work as well, and did not hit this issue until last week, when it hit hard.

I could not successfully checkout a new Subversion working copy to my SSD - period. Every attempt gave me the following message, in my case after 5-10 minutes time. Repeat attempts (update to attempt to resume the checkout) would cause it to happen again until finally the workspace could not be updated or cleaned.

Each time I would see the following error:

Error Can't move
Error '...\path\to\.svn\tmp\entries' to
Error '...\path\to\.svn\entries': The file or directory is corrupted and unreadable

Following this, the next reboot windows would schedule a CHKDSK on my SSD drive. Despite it not finding any issues, I still got a sinking feeling. Checkouts to my regular hard disk worked fine, aside from crawling in comparison. Hmm... As it turns out - my SSD did not have corruption problems. It also isn't TortoiseSVN's fault. It's a bug in Windows 7.


Fortunately, there is a secret agent style hotfix (email registration, download link with password that expires in a few days) that came out in June. It will apparently be included in Service Pack 1 when it is released.

Symptoms listed from the hotfix described exactly the behavior I was seeing:

For example, you run an application that uses the MoveFileEx() function to replace files. If you use this function more than one time in a short time, you may receive an "ERROR_FILE_CORRUPT" error message. Additionally, you may encounter one of the following issues:A warning message is displayed in the notification area. This warning message indicates that you should run the Chkdsk.exe utility to check the disk.
A disk check is scheduled for the next time that you start the computer.

Subversion uses the MoveFileEx() method for replacing files in place. The reason this didn't happen on my regular HDD, is that the issue is specifically when MoveFileEx() is called in fast succession. SSDs perform the actions must faster. They are apparently so fast, they uncover obscure filesystem implementation bugs in NTFS. Have I mentioned SSDs rock for development?

For the curious - file indexing and anti-virus could also apparently make this problem worse / more apparent, but disabling Antivirus did not help in my case. I didn't try disabling indexing, but I did not have whole-drive indexing enabled anyway. The hotfix completely resolved the behavior on my machine.

Here are some other reference links I found helpful. Hurrah for ServerFault, which had the first useful result in Google.

http://serverfault.com/questions/72561/64-bit-tortoisesvn-on-windows-7-says-file-or-directory-is-corrupted-and-unreadab

http://tinyurl.com/w7corrupt

It both amazes me, and ceases to surprise me that bugs like this shipped in a production OS. I mean...think of the madness one could go through thinking your HDD was corrupt, or software faulty, if you just believed the messages and didn't search. It is due to this that I post this entry, hopefully it will save at least one person a few wasted minutes.

This is also the second hard drive related issue I have encountered with Windows 7 so far. The other had to do with my 1TB hard drive disappearing after resuming from standby - it was something along the lines of Windows 7 not waiting long enough for drives to respond on wakeup, and larger drives can take longer to wake up and respond. I forget if I had to apply a hotfix, or update a driver or registry setting to fix that problem.

This isn't a rant about Microsoft, this is just another good example that writing software is HARD.