locked
File Corruption not from a bug RRS feed

  • Question

  • Shortly after building my WHS box, I had a crash due to a loose SATA power adapter.  This happened while I was transferring a bunch of music to the server.  This caused a corruption and I had to do a server reinstallation.

    When WHS came up after install, everything was fine except, I had a file conflict.  Three files, all in the same folder (which was the last folder that was transferred before the crash)  claim that access is denied.  When I browse to these files, they do not exist, the folder is empty, and I cannot delete it.

    The files that are claimed to be in conflict are two albumart jpgs and strangley a desktop.ini file.

    Any ideas how I can clear up the file conflicts?  I have tried several ways of deleting the folder, but since it is headless, I have not tried hooking up a monitor, keyboard, and floppy in order to boot from floppy and delete the folder there, though I will if it is the only option.

    Thanks in advance.
    Friday, January 16, 2009 5:10 AM

Answers

  • We have now a few more things to try, all of them are unsupported, not tested and may have unwanted side effects.

    Option 1: Use a Vista DVD and boot the server from it.

    • Open the cmd prompt of the repair environment and try the fsutil command from here. (The drive letter for D: may be different in this environment, so check for the Shares folder.)


    Option 2: Check permissions.

    • Log on locally as Administrator.
    • With Windows Explorer, navigate to the folder within D:\shares.
    • Right click the file and select Properties.
    • On the Security tab verify the permissions set to the file (Administrators should have Full Control).
    • If this is not the case, click Advanced, select the owner tab and assign the ownership to the Administrator account.
    • Give the account Full Control and try to delete the file again.


    Option 3: Create Dummy files

    • Log on locally as Administrator.
    • With Notepad, create a new text file.
    • Save it under the name (including extension!) of the troublesome file.
    • Put it to the original and duplicated locations on the disks via C:\FS\<volumemountpoint>\DE\shares and/or D:\DE\shares.
    • Reboot the server.
    • Try to access the file via shortcut Shared folders on server and rename it to extension .txt.
    • If this is possible, you should also be able to delete it from here. In case this works now:
    • Wait for completion of the duplication cycle (happens each full hour) and check again, if also all copies from the DE folders on the drives have been gone.
    • If not, delete them manually.


    Option 4: Try Unlocker from here. (usually made against locked files in the network, but I had also some good results on production servers to determine and kill the process holding the file caught. (But it were always normal files, not tombstones.)

    Option 5: Perform a server reinstall.
    (Prefered to a new primary disk.)

    Best greetings from Germany
    Olaf

    • Marked as answer by Bugga360 Saturday, January 17, 2009 3:48 PM
    Saturday, January 17, 2009 11:25 AM
    Moderator
  • Option 1 - I don't have a CD/DVD drive hooked up to the server at this point in time.

    Option 2 - When I view properties for these files, there was no security tab.  I tried to force by applying new permissions to the containing folder.  Did not work...

    Option 3 - Did not work...

    Option 4 - Success!!!!!  After deleting with Unlocker and a reboot, Network is healthy!

    Thanks to all for all the continued help!
    • Marked as answer by Bugga360 Saturday, January 17, 2009 3:52 PM
    Saturday, January 17, 2009 3:52 PM

All replies

  • Bugga360 said:

    Shortly after building my WHS box, I had a crash due to a loose SATA power adapter.  This happened while I was transferring a bunch of music to the server.  This caused a corruption and I had to do a server reinstallation.

    When WHS came up after install, everything was fine except, I had a file conflict.  Three files, all in the same folder (which was the last folder that was transferred before the crash)  claim that access is denied.  When I browse to these files, they do not exist, the folder is empty, and I cannot delete it.

    The files that are claimed to be in conflict are two albumart jpgs and strangley a desktop.ini file.

    Any ideas how I can clear up the file conflicts?  I have tried several ways of deleting the folder, but since it is headless, I have not tried hooking up a monitor, keyboard, and floppy in order to boot from floppy and delete the folder there, though I will if it is the only option.

    Thanks in advance.


    Album Art jpgs and desktop.ini files are usually hidden.  Did you enable Show Hidden Files and Folders on your client?
    Friday, January 16, 2009 5:20 AM
    Moderator
  • Yes.  I forgot to mention that.  The first thing I did to locate the files was to check that hidden and system files were shown.

    EDIT After this post, I remembered that showing system files was a different setting.  You were correct, they were hidden.  Now that I can located the files, how do I delete them?  There are also two more files in that folder one of which cannot be accessed and the other cannot read from source or disk.
    Friday, January 16, 2009 5:25 AM
  • Bugga360 said:

    Yes.  I forgot to mention that.  The first thing I did to locate the files was to check that hidden and system files were shown.


    Did you try creating a file with the exact same name on your client, then copying it to the server (hopefully to overwrite the file it's seeing)?
    Friday, January 16, 2009 5:31 AM
    Moderator
  • Yes, and just tried again.  Does not work (Access denied)

    Also, it may be worth noting that these five files range in size from 0kb to 3kb.
    Friday, January 16, 2009 5:34 AM
  • The file replacement method just worked on the file that was unable to read from source or disk.  After I deleted that, the other "new" broken file disappeared with it.  Now I am left with the original three problem files (the only files that show as in conflict.
    Friday, January 16, 2009 5:40 AM
  • Bugga360 said:

    Yes, and just tried again.  Does not work (Access denied)

    Also, it may be worth noting that these five files range in size from 0kb to 3kb.


    Well, the only option left is unsupported but it should work.  Logon to the server desktop and start checking where the actual files are stored (what you see from the shares are only tombstones).  The actual data files are stored in D:\DE\shares and C:\fs\x\DE\shares (where x is a random letter/number representing a secondary drive).  Follow the path shown in the File Conflict error and check each of those locations listed above to hopefully find your broken files.  I would then copy those files to another location (server desktop perhaps), then delete those files and folders (and only those files and folders).  Once you've done that, copy the album art and desktop.ini back to the server (make sure you use the network share path).
    Friday, January 16, 2009 5:47 AM
    Moderator
  • I've tried that, and I cannot delete the primary version (the one on the D drive EDIT(d:\shares\..)), but all other versions I find I can, and have deleted.  I don't think this is a WHS issue as much as it is a corrupt file issue.  I have no worries about losing these files, so anyway I can delete them I am trying.

    I am thinking about trying moveonboot, but am not sure if I can run that headless.  Any idea if moveonboot requires user input to allow the system to progress to a state where rdp is available? EDIT(I tried moveonboot in delete mode to no avail.  Files are still there...)
    Friday, January 16, 2009 5:53 AM
  • The file in D:\shares you can delete by issuing a command like
    fsutil reparsepoint delete path\filename
    to remove the tombstone to the no longer existing file.
    Best greetings from Germany
    Olaf
    Friday, January 16, 2009 7:57 AM
    Moderator
  • When I try that, I get access denied...
    Friday, January 16, 2009 1:22 PM
  • So try to run
    chkdsk /v /f /r d:
    from a command prompt on your server.
    Best greetings from Germany
    Olaf
    Friday, January 16, 2009 1:56 PM
    Moderator
  • I ran chkdsk and I still have the same problem.  The access to the files is denied...

    Any ideas?
    Saturday, January 17, 2009 6:01 AM
  • We have now a few more things to try, all of them are unsupported, not tested and may have unwanted side effects.

    Option 1: Use a Vista DVD and boot the server from it.

    • Open the cmd prompt of the repair environment and try the fsutil command from here. (The drive letter for D: may be different in this environment, so check for the Shares folder.)


    Option 2: Check permissions.

    • Log on locally as Administrator.
    • With Windows Explorer, navigate to the folder within D:\shares.
    • Right click the file and select Properties.
    • On the Security tab verify the permissions set to the file (Administrators should have Full Control).
    • If this is not the case, click Advanced, select the owner tab and assign the ownership to the Administrator account.
    • Give the account Full Control and try to delete the file again.


    Option 3: Create Dummy files

    • Log on locally as Administrator.
    • With Notepad, create a new text file.
    • Save it under the name (including extension!) of the troublesome file.
    • Put it to the original and duplicated locations on the disks via C:\FS\<volumemountpoint>\DE\shares and/or D:\DE\shares.
    • Reboot the server.
    • Try to access the file via shortcut Shared folders on server and rename it to extension .txt.
    • If this is possible, you should also be able to delete it from here. In case this works now:
    • Wait for completion of the duplication cycle (happens each full hour) and check again, if also all copies from the DE folders on the drives have been gone.
    • If not, delete them manually.


    Option 4: Try Unlocker from here. (usually made against locked files in the network, but I had also some good results on production servers to determine and kill the process holding the file caught. (But it were always normal files, not tombstones.)

    Option 5: Perform a server reinstall.
    (Prefered to a new primary disk.)

    Best greetings from Germany
    Olaf

    • Marked as answer by Bugga360 Saturday, January 17, 2009 3:48 PM
    Saturday, January 17, 2009 11:25 AM
    Moderator
  • Olaf Engelke said:

    We have now a few more things to try, all of them are unsupported, not tested and may have unwanted side effects.

    Actually, Option 5 is supported. ;)

    Olaf Engelke said:

    Option 1: Use a Vista DVD and boot the server from it.

    • Open the cmd prompt of the repair environment and try the fsutil command from here.


    Option 2: Check permissions.

    • Log on locally as Administrator.
    • With Windows Explorer, navigate to the folder within D:\shares.
    • Right click the file and select Properties.
    • On the Security tab verify the permissions set to the file (Administrators should have Full Control).
    • If this is not the case, click Advanced, select the owner tab and assign the ownership to the Administrator account.
    • Give the account Full Control and try to delete the file again.


    Option 3: Create Dummy files

    • Log on locally as Administrator.
    • With Notepad, create a new text file.
    • Save it under the name (including extension!) of the troublesome file.
    • Put it to the original and duplicated locations on the disks via C:\FS\<volumemountpoint>\DE\shares and/or D:\DE\shares.
    • Reboot the server.
    • Try to access the file via shortcut Shared folders on server and rename it to extension .txt.
    • If this is possible, you should also be able to delete it from here. In case this works now:
    • Wait for completion of the duplication cycle (happens each full hour) and check again, if also all copies from the DE folders on the drives have been gone.
    • If not, delete them manually.

    Option 4: Try Unlocker from here. (usually made against locked files in the network, but I had also some good results on production servers to determine and kill the process holding the file caught. (But it were always normal files, not tombstones.)

    Option 5: Perform a server reinstall.
    (Prefered to a new primary disk.)

    Best greetings from Germany
    Olaf



    I would try Option 2 first.
    Saturday, January 17, 2009 3:43 PM
    Moderator
  • Option 1 - I don't have a CD/DVD drive hooked up to the server at this point in time.

    Option 2 - When I view properties for these files, there was no security tab.  I tried to force by applying new permissions to the containing folder.  Did not work...

    Option 3 - Did not work...

    Option 4 - Success!!!!!  After deleting with Unlocker and a reboot, Network is healthy!

    Thanks to all for all the continued help!
    • Marked as answer by Bugga360 Saturday, January 17, 2009 3:52 PM
    Saturday, January 17, 2009 3:52 PM