Add an automatic merge convenience feature

[mirh]

Now, I get that recuperabit has the most sophisticated recovery algorithm ever.
And with the godsent help of #68 I could even find 31 possible locations for one of my missing photos (of which 5 were even good and 3 only partially unreadable). As opposed to 13 random files by NTFS Recovery (which still had 1 okay though).

But one very useful feature that has (aside of the GUI /s) is that it could present to me the files in a single "unified virtual disk" view. No hundreds of separate tentative "partitions".
I don't really know if that's just deriving some information better from my disk image, or if it isn't using some post hoc trick (for example, if in any partition you find the actual "long path" of some file, then you assign all the elements with the same index to its same parent) ... But it would be nice if this also worked here.

Of course, please, by all means take your time to finish the conversion to python3 first d:

[Lazza]

No hundreds of separate tentative "partitions"

I think there is a little misunderstanding here. What other tools do is this:

• find a boot sector and related partition boundaries
• assume by default that every single MFT entry found within those boundaries MUST be part of that partition
• basically ignore the fact that there could have been previous overwritten partitions

That one is a tentative approach. Conversely, RecuperaBit only merges stuff that can be merged without random assumptions. For instance, different parts of the same MFT almost always get detected and merged correctly.

But being a digital forensics tool it cannot "invent" information that is not there. In some cases a skilled analyst could be able to ascertain that other parts can be merged, but the software cannot do that.

if in any partition you find the actual "long path" of some file, then you assign all the elements with the same index to its same parent

That could be doable in some simple cases, but if the data runlists differ (for instance, the disk has been defragmented... which often leads to a lot of bogus partitions), how do you decide which one is correct?

[mirh]

Weell, I don't know, to be honest I was just extrapolating from a pattern I was seeing in the files I was recovering.
And I feel stupid having gone at such lengths to think this procedure, when it could have just been the easier "put everything into the same bin"..

Anyway, I guess like rather than an "easy mode", the option instead could just be about some kind of "single partition" assumption?
I personally feel like this would be the main use case for most people (uh.. at least if we assume windows system reserved partition is negligibly small? I am recovering a Vista system, so I wouldn't know if a whole disk image goes as smooth once you add that)

[Lazza]

It's not so easy: if you put everything in one bin, you might encounter multiple files with the same id. Then you have to decide what parts to keep.

[mirh]

Nothing wrong with that.
You can still put them together, and then rename each new id like File1, File2, File3 etc..

[Lazza]

That's not how the reconstruction work, the identifiers must be unique.

[mirh]

Yes, I understand (I think). In my use case above for example I had 31 unique identifiers for some given path and file name.
What I'm hoping for is for each of them to be reconstructed in a folder with some easy and quick procedure.

Because using the windows image viewer to pick up the best recovered pictures, is far easier then than just "guessing from CLI", if I can explain.