locked
How Can I Determine What Files Given File Record Segments Point At? RRS feed

  • Question

  • I am running NTFS, and I have a 2TB volume with lots of files on it.  Fortunately, I have cloned the entire volume to another 2TB volume on occasion (using WinDD, but basically an exact bit-by-bit image of the entire 2TB).  Unfortunately, the volume I normally work with has failed, and my last clone was pretty old.  To deal with this, I switched to Linux and used ddrescue to get as much of the failed drive recovered as I could.  When I finally gave up on the recovery (after weeks, but it looked like it would take years to get much more of value), I was left with 1.3MiB of bad space in two or three sections of the volume, mostly in 1kiB sections (usually there were 2 bad sectors followed by some number of good sectors followed by 2 more bad sectors, etc.).  The volume had 64kiB clusters, so that still potentially left a lot of corruption.  After all of this, I took the newly cloned (from bad drive) volume back to windows and ran chkdsk.  It found 1 corrupt file segment, 336 orphan file segments, and 440 bad index entries.  So it deleted all of those (which included about 6 folders that got moved to the chkdsk found folder, the rest was individual files that are now gone).  I don't know what files are gone, but I do know that most of the files lost are likely on my older good clone of the volume.  Comparing the volumes folder by folder, would be a nightmare, and I assume can't easily use a tool (or find a free one) because of the number of changes that weren't backed up.  I have the log from chkdsk saved so I can sort through this.  Can anyone tell me of a good way to find out what files the deleted file record segments point at on the volume where they haven't been deleted?  For example, here are two records from the chkdsk log:

    Deleting corrupt file record segment 1107859.

    Deleting orphan file record segment 1069930.

    Since I know specifically what file record segment I need to look at on the good clone, can I somehow extract the file information regarding those file segment numbers from the MFT?

    Note that I don't have to use XP for this, that just happens to be where the volume was created and repaired.



    • Edited by The00Dustin Friday, September 21, 2012 1:39 PM previous edit was to fix two spelling errors, clarify clone type, this edit was to enter reason
    Wednesday, September 19, 2012 5:18 PM

Answers

  • Well, I finally had a chance to try out some Linux-based ntfs utilities.  I am not sure whether they are from ntfs-3g, ntfsprogs, or ntfsutils, but anyone who has a favorite linux distro should be able to fire it up and get the information I needed pretty easily.  The numbers are inode numbers, and two commands were very helpful.  This one provided what I needed:

    ntfscluster -I <inode # / file record segment #> <partition path>

    It included the full path to the file in question and very little other information.  This command provided a whole lot of information I didn't need:

    ntfsinfo -i <inode # / file record segment #> <partition path>

    It didn't provide the path, but did provide the inode number of the parent directory, so you could reverse engineer the path by using this command over and over.

    • Marked as answer by The00Dustin Wednesday, October 3, 2012 10:03 PM
    Wednesday, October 3, 2012 10:03 PM

All replies

  • First, I just want to say that I don't know how to tell what file it refers to by the record segments.  Just a couple of thoughts though....When you ran the chkdsk, did you run a chkdsk /f?  I believe that will recover the file instead of deleting it.  Also, have you ever heard of a program called Stellar Phoenix?  I bought it a couple of years ago and it works really well for recovering data on corrupt drives.  They have a free download on their site to run a diagnostic and see what can be recovered then it's like $50-100 to buy the program.  If you are able to find out how to decipher the record segments, please post because I'd like to know how. 

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, September 19, 2012 6:36 PM
  • I think the file record segments are pointers to sectors of the drive, but I hope they are also linked to file names in the MFT.

    Regarding chkdsk, if you don't run it with /f, it takes no action.  I did run it with /f, and that was the action it took, but there was no way it could recover this data, because it didn't exist on the volume I was repairing.

    I haven't heard of Stellar Phoenix, but I am confident I recovered all of the data that was going to be recovered in a reasonable timeframe, and I have since RMAed the defective drive.

    I will definitely update my threads if I find a solution, I always try to remember to do that.

    Saturday, September 22, 2012 11:56 AM
  • Well, I finally had a chance to try out some Linux-based ntfs utilities.  I am not sure whether they are from ntfs-3g, ntfsprogs, or ntfsutils, but anyone who has a favorite linux distro should be able to fire it up and get the information I needed pretty easily.  The numbers are inode numbers, and two commands were very helpful.  This one provided what I needed:

    ntfscluster -I <inode # / file record segment #> <partition path>

    It included the full path to the file in question and very little other information.  This command provided a whole lot of information I didn't need:

    ntfsinfo -i <inode # / file record segment #> <partition path>

    It didn't provide the path, but did provide the inode number of the parent directory, so you could reverse engineer the path by using this command over and over.

    • Marked as answer by The00Dustin Wednesday, October 3, 2012 10:03 PM
    Wednesday, October 3, 2012 10:03 PM