Windows 7: Bogus ERROR_FILE_CORRUPT error
Written by Hyrum Monday, 08 February 2010 14:28
Subversion performs a lot of tricks, on the both client and server, to keep your data safe. Even in the event of a random power failure or bug in the program, Subversion is designed to make sure your data isn't lost. One of the most common tricks Subversion uses is to take advantage of the underlying operating system's "atomic file move" APIs to make sure a file is never half-written to disk. By first writing a temporary file, and then atomically moving that file into the correct location, Subversion can be sure all of the content is written or none of it is; you don't get half-baked data.
The above approach works great, and is portable to a large number of operating systems. It works great, that is, until there is a bug in the underlying operating system. Microsoft has been kind enough to introduce such a bug in Windows 7.
Windows 7 introduces the concept of the "oplock" for locking file access. The APIs which Subversion uses for platform portability have been updated to use oplocks. In previous versions of Windows, if two applications, such as a virus scanner and Subversion, were to attempt to access the same file, one would get an "Access Denied" error, which that application could then notice and use to retry the access later.
Windows 7, in contrast, emits a "File Corrupted" error in this same scenario. Not only does the calling application not know how to handle the error, this error also gets propagated to the operating system. Windows displays a notice to the user in the system tray, and a complete check disk gets scheduled for the next reboot. To an unsuspecting user, this could look like a serious application bug, or even some kind of hardware failure. Scary stuff!
The key thing here, though is that even though Windows reports corruption, and even though it runs a check disk on the next reboot, no corruption has actually occurred. The check disk runs without incident, and the file contents are unmodified, but the buggy API has caused a confused user, and lots of wasted time.
Microsoft has confirmed this bug:
This is a known regression in Windows 7 in the NTFS file system. It occurs when doing a superseding rename over a file that has an atomic oplock on it (atomic oplocks are a new feature in Windows 7). The indexer uses atomic oplocks which is why it helped when you disabled the indexer. Explorer also uses atomic oplocks which is why you are still seeing the issue. When this occurs STATUS_FILE_CORRUPT is incorrectly returned and the volume is marked "dirty" which is a signal to the system that chkdsk needs to be run. No actual corruption has occurred.
Although this is a bug in Windows itself, there are a few workarounds you can try. Disabling the indexing service, as well as anti-virus scanners will decrease the chance of encountering this error. Subversion 1.7, with the next generation working copy library, will remove many of the scenarios where Subversion needs to do the "atomic rename" trick. But ultimately, the fix will have to come from Microsoft, so I encourage you to use whatever means you have to lobby Microsoft to fix the problem and issue a hot fix.
You can track the status of the bug, via Microsoft's TechNet forums here:
http://social.technet.microsoft.com/Forums/fi-FI/w7itprogeneral/thread/df935a52-a0a9-4f67-ac82-bc39e0585148
You can visit the Subversion issue which tracks this bug here:
http://subversion.tigris.org/issues/show_bug.cgi?id=3574
Subscribe to this comment's feed
written by Elger, March 13, 2010
-
- -3
-
-
written by Morris Maynard, March 31, 2010
-
- +2
-
-
written by Walter Hop, April 11, 2010
-
- +2
-
-
