I recently ran into a problem on my fancy new machine while trying to commit a rather large number of files into an SVN repository. The error message stated that some of the files in the .svn control directory had become corrupted and unreadable.

After Googling around a bit I came across a post on the CollabNet issue log which identified this as an issue with the NTFS stack on Windows 7. This post included another link to a Microsoft technet discussion about the issue.

The long and the short of it is that this is an identified issue in the NTFS implementation in all editions of Windows 7 (both 32 and 64 bit versions). The indexing service is locking files which SVN is trying to move. This only appears to be a problem with large batch transactions. Smaller ones, for me at least, have been working just fine but YMMV.

In case you don’t want to read the whole discussion thread, here’s the response from the NTFS team developer who responded to the community reports:

This is a known regression in Windows 7 in the NTFS file system.  It occurs when doing a superceding 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 occured. Neal Christiansen NTFS Development Lead

The identified workaround for this issue is to stop the indexing service. If you don’t use search very often you can disable it. If you do, you can just stop the service and allow it to restart the next time you restart Windows.

The next trick, of course, is finding the indexing service.  In Windows 7 the service has been renamed “Windows Search”. It serves essentially the same functions as the old “Indexing Service”.

There have been some reports that this issue affects Windows Vista as well, but I don’t have a Vista machine to test with.

Apple’s hardware always returns time in UTC, most PCs update the system clock to local time and won’t require a conversion of that time so of course the default Windows settings aren’t really set up for BootCamp (though you’d think the BootCamp installer could correct this…)

The solution, as it turns out, is a simple registry key change to tell Windows that the system’s clock is using UTC time.  One value in one key, that’s all it takes:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTimeZoneInformation] "RealTimeIsUniversal"=dword:00000001

BootcampUtcClockFix.reg

Another solution that I found over at superuser.com is to modify OS X to change the time at startup and at shutdown. To me, this seems like more of a hack than the “unsupported” registry key. Windows 7 has been working well under this configuration and has even successfully interpreted the daylight saving time change.