none
Getting ERROR_FILE_CORRUPT when moving a file... Result: Chkdsk at reboot (Reproducable and confirmed)

    Question

  • Many tools use tempfiles to create a new file and then use MoveFileEx to move the tempfile over the existing file.

    In some cases Subversion does this multiple times in just a second. In this case Windows 7 starts returning ERROR_FILE_CORRUPT where older Windows versions returned ACCESS DENIED like errors.

    This is not a big deal by itself, but this error is also broadcasted to other parts of the system.

    * You get a statusbar popup indicating that you should run chkdsk.exe to check your disk
    * A chkdsk run is scheduled for the next reboot. (!!!)
    (Several Subversion users have declared their harddisk broken because of this bug misreporting one error after another)

    I can replicate this behavior with a simple C++ program on Windows 7 (multiple versions on different PC's), but I can't replicate this issue on Windows Vista or older systems.
    (These start returning access denied constently).

    Can somebody tell me what the right location is to report this issue and to get this issue fixed?

    [Added 10 minutes later]
    Disabling the file indexing on the directory helps in our real world cases; but this should never cause this anyway, and it doesn't fix this specific testcase for me. It just sometimes takes a bit longer to reach the error state.

    [Added 30 minutes later]
    The expected output on Windows 7 is something like:
    ---- (+-90%: Direct failure)
    Starting test run
    Moving failed: error 1392
    Directory or file corrupted in 133 iterations
    --- (+-10%: First a few access denieds)
    Starting test run
    Moving failed: error 5
    Moving failed: error 5
    Moving failed: error 5
    Moving failed: error 5
    Moving failed: error 5
    Moving failed: error 1392
    Directory or file corrupted in 1155 iterations
    ---
    On Windows vista you only get the access denied (error 5) and the application doesn't quit.

    If you explicitly mark the directory as not to be indexed by Windows search and disable your virusscanner you get +- the Vista behavior. Either one of these can get you the errors.

    ----------------------------------------------------------------------------------------------------------
    // CorruptDir.cpp : Shows file corruption issue (use cl -o CorruptDir.exe CorruptDir.cpp)

    #define WINVER 0x0600

    #include <windows.h>
    #include <shlobj.h>
    #include <atlstr.h>

    CString GetMyDocuments()
    {
     LPWSTR pMyDocuments;
     SHGetKnownFolderPath(FOLDERID_Documents, 0, NULL, &pMyDocuments);

     CString result = pMyDocuments;
     CoTaskMemFree(pMyDocuments);

     return result;
    }

    static const char *someDataToWrite = "Some data to put in the file\n";


    int _tmain(int argc, _TCHAR* argv[])
    {
     CString workDir = GetMyDocuments() + "\\IndexedDir";
     CString workFile = workDir + "\\real";
     CString tmpFile = workDir + "\\temp";
     int n = 0;

     // Create testplace and clear previous results
     CreateDirectory(workDir, NULL);
     DeleteFile(tmpFile);
     DeleteFile(workFile);

     printf("Starting test run\n");
     while (TRUE)
     {
      n++;
      // Create tempfile
      HANDLE hTemp = CreateFile(tmpFile, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, NULL, CREATE_ALWAYS, 0, NULL);

      if (hTemp == INVALID_HANDLE_VALUE)
      {
       DWORD err = GetLastError();

       printf("Temp file creation failed: error %d\n", err);

       if (err == ERROR_DISK_CORRUPT || err == ERROR_FILE_CORRUPT)
       {
        printf("Directory or file corrupted in %d iterations\n", n);
        return 1;
       }

       continue;
      }

      DWORD dwWritten;
      ::WriteFile(hTemp, someDataToWrite, strlen(someDataToWrite), &dwWritten, NULL);
      ::CloseHandle(hTemp);

      // And now move the tempfile over the existing file
      if (!MoveFileEx(tmpFile, workFile, MOVEFILE_REPLACE_EXISTING))
      {
       DWORD err = GetLastError();

       printf("Moving failed: error %d\n", err);

       if (err == ERROR_DISK_CORRUPT || err == ERROR_FILE_CORRUPT)
       {
        printf("Directory or file corrupted in %d iterations\n", n);
        return 1;
       }
      }
     }

     return 0;
    }

     

    • Edited by Bert Huijben-TCG Sunday, February 07, 2010 8:50 PM Update title to match status
    Wednesday, February 03, 2010 2:16 PM

Answers

  • 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
    Thursday, February 04, 2010 8:59 PM
  • I can confirm this problem.

    I compiled your source and saw the same thing you did. 

    Starting test run
    Moving failed: error 1392
    Directory or file corrupted in 393 iterations

    Error 1392 is ERROR_FILE_CORRUPT

    This was displayed on the TaskBar:



    Fortunately, CHKDSK found no problems.

    I run Windows Ultimate x64, Avast Antivirus, default indexing settings.

    By the way, I have not seen any problems with Subversion.

    -Noel


    P.S., I ran it for a long time on a Vista x64 system, on which I have disabled indexing (by stopping the Windows Search service), and it never emitted any error.  Same thing with a Windows 7 32 bit system.  Could this be a VERY good reason for disabling indexing?

    Wednesday, February 03, 2010 5:07 PM
  • One other thing:  The above message DOES cause a CHKDSK /F to be scheduled at reboot!!

    The Indexing service is now history on my Windows 7 machines.

    -Noel
    Wednesday, February 03, 2010 6:15 PM
  • Hi Neal,

    thanks for this information!

    Please reply when a hotfix is available to fix this and tell us the KB number!

    André

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Friday, February 05, 2010 2:16 PM
  • Geez, I'd certainly expect that such an important fix should roll out to us all in a Windows Update when they're confident in the change.

    Great to hear there's a fix in the works.

    Microsoft:  It would be ASTOUNDINGLY GREAT if we'd hear of fixes in the works to a lot of the bugs being reported.  Why no feedback to the user community about these things in general?  All silence does is breed contempt.

    -Noel
    Friday, March 12, 2010 9:17 PM
  • The hotfix for this issue will is released under KB982927. You can request this from Microsoft Support while we are working on publishing the article. As soon as it is released I will update this thread.

    The KB article is now public @ http://support.microsoft.com/kb/982927

    \Rob

    • Proposed as answer by RobSchee Thursday, June 17, 2010 5:20 AM
    • Marked as answer by Bert Huijben-TCG Monday, June 21, 2010 7:49 AM
    • Edited by RobSchee Tuesday, June 22, 2010 8:55 AM
    Thursday, June 17, 2010 5:20 AM
  • I opened a support incident for this issue via my employer. The Incident ID is: SRZ100208000167.

    The Microsoft issuenumber is:

    Windows SE 300176 - fsrtlcheckoplock should return status_pending upon atomic oplock in filerenameinformation/filelinkinformation cases



    Bert
    Monday, February 08, 2010 11:50 AM
  • Microsoft is working on a patch which is currently being tested. (I don't know about the release plans yet).

    My tests of this preliminary patch are promissing. (Even running the corruptdir app for a night doesn't show any corruptions)
    Thursday, March 11, 2010 5:04 PM
  • Thanks for making a hotfix. I've already installed a newer LDR kernel (7600.20714 (KB983401)) with includes that fix.

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Thursday, June 17, 2010 2:49 PM

All replies

  • I can confirm this problem.

    I compiled your source and saw the same thing you did. 

    Starting test run
    Moving failed: error 1392
    Directory or file corrupted in 393 iterations

    Error 1392 is ERROR_FILE_CORRUPT

    This was displayed on the TaskBar:



    Fortunately, CHKDSK found no problems.

    I run Windows Ultimate x64, Avast Antivirus, default indexing settings.

    By the way, I have not seen any problems with Subversion.

    -Noel


    P.S., I ran it for a long time on a Vista x64 system, on which I have disabled indexing (by stopping the Windows Search service), and it never emitted any error.  Same thing with a Windows 7 32 bit system.  Could this be a VERY good reason for disabling indexing?

    Wednesday, February 03, 2010 5:07 PM
  • One other thing:  The above message DOES cause a CHKDSK /F to be scheduled at reboot!!

    The Indexing service is now history on my Windows 7 machines.

    -Noel
    Wednesday, February 03, 2010 6:15 PM
  • Hi,

    The issue should be related to the design of the programs. I suggest you discuss in our MSDN forum. It should be UAC related software development question.

    Application Compatibility for Windows Development 


    Arthur Xie - MSFT
    Thursday, February 04, 2010 7:25 AM
    Moderator
  • Hi,

    The issue should be related to the design of the programs. I suggest you discuss in our MSDN forum. It should be UAC related software development question.

    Application Compatibility for Windows Development 


    Arthur Xie - MSFT

    Strange..  I wouldn't have guessed that would be an appropriate place.

    This issue has nothing to do with UAC (no access control is needed) and nothing with specific application development.

    It is most likely an issue in either NTFS or in the transactional filesystem handling as used by a simple FileMove() call while the windows search indexer looks for this directory. It is experienced by more than a few programs. Every program using the FileMove() can cause this condition and it is easy to reproduce.

    And when it is reproduced Windows sees the error and schedules a chkdsk /F (taking about 45 minutes for my huge disk) on the next reboot.

    I might be able to fix this for my applications, but then I will still see this 'chkdsk /F' if another program triggers the same issue.
    Thursday, February 04, 2010 8:02 AM
  • 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
    Thursday, February 04, 2010 8:59 PM
  • Neal, can you tell us how we can engage with a support engineer to request a fix?  Many of us suffering from this problem are Subversion users without corporate connections. 

    While it's comforting to know this isn't an actual data corruption error, it's still very annoying and causes problems with apps like Subversion, causing broken checkouts and invalid requests for usernames when none are needed.

    EDIT: Since you edited your post to remove the part about SP1, can we conclude that the fix will in fact be in SP1?  Or simply that you aren't authorized to talk about it?
    Thursday, February 04, 2010 9:25 PM
  • I'd just like to say a heartfelt "THANKS" for your taking the time to post here and to let us know you're working on the issue, Neal.

    While it's clear that there are powers in Microsoft that wish to control the flow of information, and these folks are especially sensitive to anything which can be construed as a "promise to deliver", please, please, PLEASE let those powers know that even a simple acknowledgement by you developers that an issue exists and is likely to be fixed is comforting beyond measure.

    In short, we customers simply don't hear enough from you folks, and many of those who don't understand corporate politics and policies jump to the conclusion that you're simply not listening.

    -Noel
    Friday, February 05, 2010 12:50 PM
  • Hi Neal,

    thanks for this information!

    Please reply when a hotfix is available to fix this and tell us the KB number!

    André

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Friday, February 05, 2010 2:16 PM
  • @Neal,

    Thanks for confirming that this is a known issue. I really hope we can get a broadly available fix for this issue as many Subversion users are bitten by this issue without even realizing that the issue is not an hardware problem.

    I'm just affraid that for most other applications experiencing this issue, the problem is simply seen as a hardware issue and further forgotten. (I was lucky to see the bigger issue as AnkhSVN allows reporting these errors to us, while most other applications just report the error literally to the user without notifications further up the chain).

    If I look in the eventviewer at the reported error and click on the link for more details I see a page that says that no further information is available. Maybe that should point to a knowledge base article with more information about this known issue.

    When searching the internet I see other similar issues possibly around virusscanners. The problem is that I can't determine if this is really the same issue. (I would guess that they to talk to the filesystem at the kernel level; but maybe they also use oplocks).


    Are there any known valid workarounds that leave the basic atomic operation of a replace working?
    Deleting the file and then recreating it with new contents leaves us with the possibility that we don't completely write a file. (And as Subversion tries to be mostly platform independent by using the Apache APR library the fix would have to be so generic that it can be included there without slowing down other applications that also use the same library). Some users suggest using the Transactional File apis introduced in Windows Vista, but this most likely just moves the problem. (Other race conditions with other libraries... and most likely with ourself as we don't have an existing way of handing over transactions)


    The most obvious answer for us would be that the filesystem API is fixed...
    This would make sure that we don't introduce new issues that break later... And it would remove an hidden bug from lots of other applications.

        Bert
    Saturday, February 06, 2010 2:51 PM
  • I opened a support incident for this issue via my employer. The Incident ID is: SRZ100208000167.

    The Microsoft issuenumber is:

    Windows SE 300176 - fsrtlcheckoplock should return status_pending upon atomic oplock in filerenameinformation/filelinkinformation cases



    Bert
    Monday, February 08, 2010 11:50 AM
  • Hi Bert,

    any news about this issue? Did you get a response from MS?

    André

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Tuesday, March 09, 2010 10:01 PM
  • Microsoft is working on a patch which is currently being tested. (I don't know about the release plans yet).

    My tests of this preliminary patch are promissing. (Even running the corruptdir app for a night doesn't show any corruptions)
    Thursday, March 11, 2010 5:04 PM
  • great to hear this. Now we have to wait until MS releases the hotfix to the public, so that I can request it.

    André

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Thursday, March 11, 2010 11:32 PM
  • Geez, I'd certainly expect that such an important fix should roll out to us all in a Windows Update when they're confident in the change.

    Great to hear there's a fix in the works.

    Microsoft:  It would be ASTOUNDINGLY GREAT if we'd hear of fixes in the works to a lot of the bugs being reported.  Why no feedback to the user community about these things in general?  All silence does is breed contempt.

    -Noel
    Friday, March 12, 2010 9:17 PM
  • I am having the same problem when I use Subversion (TortoiseSVN) with encrypted files (EFS) and the windows full indexing on (Windows 7 on a Dell m4400). Actually, I am getting NTFS corruption events (Event 55), yet nothing is wrong with NTFS when I use chkdsk to correct the errors.

    It is really frustrating because I use Subversion as a content management system for all my documents (including a huge knowledge base) and currently am unable to use it to its fullest (without the search function).

    Dear MS: please fix it as soon as possible - maybe before issuing the first SP? Would be so great!
    Saturday, March 27, 2010 3:13 PM
  • I found a smal Trick, but it is not for usual. If you want to branch etc. reboot, login as quickly you can, call quickly for example Visual Studio and branch. It works.

    But this BUG in NTFS is a hard BUG, don't know how MS this is managing, but in our company we have a QA and they ckeck everything, also if we develop.

    Regards

    Saturday, March 27, 2010 7:13 PM
  • @Bert: Thank you so much for pursuing this so diligently.  The (Windows 7) subversion community owes you.
    Friday, April 09, 2010 7:51 AM
  • Just to reiterate the more or less acceptable workaround I noted above:

    Stop and Disable the Windows Search indexing service.  This will work around the problem and has surprisingly little downside.

    -Noel

    • Proposed as answer by Noel Carboni Monday, May 17, 2010 10:51 PM
    Friday, April 09, 2010 2:09 PM
  • @Noel,

    Thanks for the tip about disabling the Search service.

    It allows me to checkout/update my code again :-)

    Regards


    Luc Morin, T.P. http://www.stlm.ca
    Saturday, April 24, 2010 4:01 PM
  • Microsoft Security Essentials causes a similar problem. I'm not sure if 'Disable your AV product' is good advice but it is needed if you want to do a big check-out with svn.

    Dave.

    Monday, May 17, 2010 2:49 PM
  • For what it's worth, I have Avast Pro 5 and without disabling it I can do huge SVN operations with no problems.  Avast is well worth looking into.

    -Noel

    Monday, May 17, 2010 10:51 PM
  • Great! Did you include a link to this forum? It would be outrageous if the would set it to a low priority due to a presumably low impact... It is actually not only causing problems with Subversion (which MS just couldn't care less about) but also with Office 2007 (occasionally, I cannot save my Word documents, have to create a temporary file, quit Word, start it anew, read the temporary file and overwrite the original file). I sure hope that MS takes the problem seriously... Really, my whole team is affected.
    Saturday, May 29, 2010 8:14 PM
  • The hotfix for this issue will is released under KB982927. You can request this from Microsoft Support while we are working on publishing the article. As soon as it is released I will update this thread.

    The KB article is now public @ http://support.microsoft.com/kb/982927

    \Rob

    • Proposed as answer by RobSchee Thursday, June 17, 2010 5:20 AM
    • Marked as answer by Bert Huijben-TCG Monday, June 21, 2010 7:49 AM
    • Edited by RobSchee Tuesday, June 22, 2010 8:55 AM
    Thursday, June 17, 2010 5:20 AM
  • Thanks for making a hotfix. I've already installed a newer LDR kernel (7600.20714 (KB983401)) with includes that fix.

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Thursday, June 17, 2010 2:49 PM
  • So what's the latest on this - and should this still be happening on a fully up-to-date Win 7 64-bit machine?

    I have a fairly new ASUS, and only in the last three weeks I get a chkdsk running on boot-up about every second boot. Sometimes this is after a warning of a corrupt file in the previous session; sometimes not.  I am getting file corruption warnings from two different events - when importing photos from an iPhone 4 on syncing (using the standard Win auto-start) and (less often) when using the Virtual Windows XP Mode (to run a legacy version of Quicken).

    The HDD came partitioned as C: (system) and D: (data). It seems to only be C: that is triggering chkdsk. I run all my data files in Offline Mode, synced with my home office desktop - although this seems to be working fine.

    Should I just turn off indexing? If so, what useful search alternative are there? The hotfix mentioned here doesn't seem to be for *exactly* the same situation.

    Appreciate any advice.


    Keith De La Rue
    Friday, January 21, 2011 1:54 AM
  • So what's the latest on this - and should this still be happening on a fully up-to-date Win 7 64-bit machine?

    install the hotfix KB982927 to fix it. the kernel is now switched to the LDR version (not the GDR version you get on WU) and this kernel includes the fix.

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Friday, January 21, 2011 2:49 PM
  • Andre -

    Great - thanks for following up, much appreciated. Done, and all seems fine.

    Of course, if it works fine, I'l never really know; and if I get a random chkdsk again, I'll know it *hasn't* worked. Now I know how Schrödinger's cat felt...


    Keith De La Rue
    Monday, January 24, 2011 11:11 AM
  • I am getting "Sorry, but we couldn't find the page that you requested." when I try to open: http://support.microsoft.com/kb/982927

    Is the hotfix no longer available?

    Monday, February 28, 2011 12:50 PM
  • I am getting "Sorry, but we couldn't find the page that you requested." when I try to open: http://support.microsoft.com/kb/982927

    Is the hotfix no longer available?


    it is now part of a GDR update for Windows 7 RTM:

    http://support.microsoft.com/kb/2498472/en-us

    If you use Windows 7 Sp1, the fix is already included.


    André


    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Monday, February 28, 2011 1:10 PM
  • Thanks, I'm downloading and installing SP1 right now.
    Monday, February 28, 2011 3:18 PM
  • This KB link no longer works. I'm still having this issue after upgrading to Windows 7 SP1. Can you please confirm the correct location of this and ETA for a fix?
    Thursday, March 24, 2011 11:43 PM
  • The fix is already included in Windows 7 Sp1.
    "A programmer is just a tool which converts caffeine into code"

    Want to install RSAT on Windows 7 Sp1? Check my HowTo: http://www.msfn.org/board/index.php?showtopic=150221
    Friday, March 25, 2011 1:15 PM
  • I get the Eventid 55 if I try to browse previous versions.

    I have over 1000 of them going back to the 4th of Jan 2012.  At first i thought my disk was going out but now with it being generated whenever i try to look at previous versions well i wonder if there is something wrong with how windows see's the cache for previous versions?

    Wednesday, February 22, 2012 11:17 PM