Spurious alleged file corruption on Windows 7

Question

Recently my Laptop sometimes warns about corrupted files on the hard drive (Samsung SSD PB22-JS3 TM). This has only happened so far when updating (or checking out) an SVN repository with either TortoiseSVN or the command line Subversion client.

The fun thing is that the corrupted file has always been a .svn directory (although the directory entry may contain files in that directory too, if they're small enough — which should be the case with SVN). However, when looking into the warned-about directory I notice nothing strange or unusual and don't get any more warnings about it and another try (SVN stops updating once that error occurs — TortoiseSVN even with an appropriate error message) of updating the working copy works (well, mostly; sometimes it does it again, albeit with a different directory).

Since the laptop is only a few months old I doubt the SSD is failing already—five months of normal usage shouldn't be too surprising. Also it (so far) occurred only with SVN updates on a large repository. Maybe that's too many writes in a short time and some part between the software and the hardware doesn't quite catch up fast enough or so — I don't know enough about this to actually make an informed guess here.

Anyone knows what's up here?

ETA: Note to add: I've run chkdsk (it seems to schedule itself anyway when this happens) and it didn't find anything out of the ordinary.

Answer 1

See if this is related to your problem.

Short summary: The Windows 7 NTFS file system driver has a bug that sometimes when a process tries to access a file that's in use by another process (such as a background file indexing service) it doesn't yield an “Access Denied” error which would be the normal case but instead “File Corrupted”. This in turn also causes a chkdsk to be scheduled for the next system startup. Quoting from the linked article:

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.

Answer 2

I'm experiencing similar issues with the same Samsung Drive (MMCRE28G8MXP-0VBL1 - I'm pretty sure that's from the PB22 series)

I've only had it for two weeks, but its already interrupted normal startup to run chkdisk for drive consistency a few times. No problems show up, but its definitely responding to NTFS corruption issues. In the Event Viewer, its showing me several NTFS corruption errors - Event ID: 55 Task Category 2.

I can't say for sure, but I have a feeling that the errors coincide with high-activity drive use. I've been working with several large Excel files (10MB+) concurrently and it's clear that the drive is working pretty hard to keep up. Maybe NTFS is getting "out of sync"

When it runs through chkdisk, it does mention the USN Journal, but I haven't paid close attention to it yet.