mkirkham
commented
10 months ago Fortunately it turns out directory numbers are the same (presumably pulled from the file number in the MFT) so it seems I was at least able to write something to remap my consolidated list to the new partition/file numbers instead of having to do all that from scratch after all.
I ran RecuperaBit on a 250GB disk image I am trying to recover from a drive partition that got corrupted. It took most of a day and found 55000 partitions, about 6000 recoverable, each of which a I generated a CSV file for. These CVS files contain a combined total of a bit shy of 5 million lines (file/directory entries). Just in case there was a problem I ran with the option to generate a save file. Well, after hours of working to narrow down those 5 million entries to something more reasonably representing what I wanted to recover, Windows crashed and killed RecuperaBit and everything else and had to be rebooted.
Apparently the save file does not save the reconstructed directory hierarchy as it had to go through that again taking ~18 hours, while in the mean time I spent many of those continuing to winnow down those 5 million entries. That took some of my own coding to reconstruct paths and consolidate all the data down to a list of possible partition#/file# pairs for each of ~30K files and directories, and manual sifting of those down to ~125 directories and a few files to restore, and the partition/file #s to restore and compare.
When RecuperaBit was finally done reconstructing file system structures using the save file the partition numbers were all changed, so my list of partition/file #s to restore was no longer valid. So I get to start over again from 5 million entries and consolidating down to ~125 and hope Windows doesn't crash again in the mean time.
I did use regular python the first time and pypy the second, but I am doubting that is the reason for the different partition #s.