Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
I see this on a normal hard drive occasionally as well, generally during times of extreme hard drive activity. It's never actually caused me any problems, though, and chkdsk /X doesn't find errors. I suspect it's just part of NTFS getting out of sync for a very short period of time, and causing a false positive. (I've only seen it since I turned on USN Journaling, though. Do you have USN Journaling on?) – Fake Name Mar 4 '10 at 9:58
Where are the warnings? Are you sure the warnings are hardware related and not just SVN reporting some sort of corruption in the repository? – William Hilsum Mar 4 '10 at 9:58
@Wil: Balloon tooltip in the notification area. Yes, I'm pretty sure it's related to Windows and not SVN if the NTFS driver reports to the event log at the same time. – Joey Mar 4 '10 at 10:34
@Fake: I don't remember turning anything on that isn't already on by default. But apparently it is turned on, since fsutil usn queryjournal c: gives me some data I believe shouldn't be present if it's turned off. The “Next USN” field apparently changes with every change on the volume. – Joey Mar 4 '10 at 10:40
What anti virus (if any) do you run? – mindless.panda Mar 4 '10 at 12:59
up vote 6 down vote accepted

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.

share|improve this answer
Looks like the exact issue to me. Thanks. Quoting a bit from the article to prevent link rot might be nice, though. – Joey Mar 4 '10 at 10:42
Thanks for the edit, Johannes. – Mar 28 '10 at 21:52

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.

share|improve this answer
Take a look at the accepted answer to this question. This has already been answered and it's a bug in the Windows 7 NTFS driver. It's neither specific to a brand of Flash drives nor Flash drives in general, not related to high disk activity. – Joey Mar 28 '10 at 13:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .