Lazza
Please allow dumping tree view of files of a partition to a file
Since it is possible to dump csv to a file, why can the tree command only output to stdout? It would be convenient if it was possible to automatically save the output to a file.
I, for example, had quite a large partition with lots of files. It was most convenient for me to copy&paste output of the tree command to a file, then inspect it and delete rows that were of no interest for me, only leaving these files that could be useful; and according to this list I started recovering files.
why can the tree command only output to stdout?
Well, to be honest, the tree command had the basic purpose of being useful during debugging and testing the tree reconstruction algorithm on small toy-examples. It was one of the first commands I wrote and it's quite small and humble.
I agree it should be better and this will probably be addressed in a future release.
then inspect it and delete rows that were of no interest for me
To this regard, I am actually planning a locate-like command to print file paths matching a specific string. This is going to help quite I bit, I believe.
Tbh, I don’t think any pattern-matching would be more helpful than this tree-command. What I really needed was a tool that would somehow recreate the directory structure and show it to me. Pattern-matching could only be helpful if I remembered exactly well the names of the folders that were lost. I didn't. Only glancing at the directory structure could give me reasonable sureness I didn’t miss anything important. Thanks to the indentation, I could reasonably easily delete whole folders I didn’t care about.
Also, there’s one more important thing. Sometimes RecuperaBit was failing to correctly recreate metadata. For example, once it erroneously placed a bunch of important files to a folder that was incorrectly named after a hidden temp file. I have no complaints about this, I know no file recovery software can perform miracles and when lots of important files accidentally get deleted I am very grateful for anything that could be recovered. I’d only like to point out that in this scenario pattern matching would be unlikely to be helpful. When scrolling through the output of the tree command I could notice that there were files of interesting names where they were not supposed to be, and manually fix the errors in the file structure.
Not that this pattern-matching would be useless. I imagine it could be pretty useful in some scenarios. I’m only reporting that in my particular case the tree command proved to be very useful and convenient.
(In theory, the pattern-matching could be regarded as secondary to the tree command, since if you managed to dump tree's output to a file, you can then grep through this file or sth like that.)
Yes, the tree command is useful although currently it's not very versatile. I consider this issue valid and I will make it better in the next updates.
Actually, most of the command line interface should be improved and probably I will make it so every command can either print to the CLI or save the output to a file. It may take a bit for this last idea, though. 😉
Pattern-matching could only be helpful if I remembered exactly well the names of the folders that were lost.
My current (unpolished, not yet released) implementation can be used to deduce the identifier of a directory without passing the exact name. For instance one could do:
> locate 0 jpg
Rebuilding partition...
Done
[547]: Root/pictures/Abstract_Ubuntu_by_Marek_Koteluk.jpg
[548]: Root/pictures/Blue_by_dariuskws.jpg
[549]: Root/pictures/Breaker_by_Lyle_Nel.jpg
[550]: Root/pictures/Hotel_by_sarcasmrules2011.jpg
[551]: Root/pictures/Light_my_fire_evening_sun_by_Dariusz_Duma.jpg
[552]: Root/pictures/Mediterranean_Sea_by_simosx.jpg
[553]: Root/pictures/Moss_inflorescence_by_carmelo75.jpg
[554]: Root/pictures/Sitting_Here,_Making_Fun_by_Philipp_Haegi.jpg
[556]: Root/pictures/Tramonto_a_Scalea_by_Renatvs88.jpg
[557]: Root/pictures/Tranquil_by_Pat_David.jpg
Write command ("help" for details):
> locate 0 pictures
[546]: Root/pictures
[547]: Root/pictures/Abstract_Ubuntu_by_Marek_Koteluk.jpg
[548]: Root/pictures/Blue_by_dariuskws.jpg
[549]: Root/pictures/Breaker_by_Lyle_Nel.jpg
[550]: Root/pictures/Hotel_by_sarcasmrules2011.jpg
[551]: Root/pictures/Light_my_fire_evening_sun_by_Dariusz_Duma.jpg
[552]: Root/pictures/Mediterranean_Sea_by_simosx.jpg
[553]: Root/pictures/Moss_inflorescence_by_carmelo75.jpg
[554]: Root/pictures/Sitting_Here,_Making_Fun_by_Philipp_Haegi.jpg
[555]: Root/pictures/Suru_Wallpaper_Desktop_4096x2304_Gray.png
[556]: Root/pictures/Tramonto_a_Scalea_by_Renatvs88.jpg
[557]: Root/pictures/Tranquil_by_Pat_David.jpg
[558]: Root/pictures/warty-final-ubuntu.png
And then restore 0 546. 😁
Also, as a medium/long-term goal I would like to add a kind of interactive browser similar to TestDisk so that one could browse inside the directories and select them for recovery with a keypress.
Sometimes RecuperaBit was failing to correctly recreate metadata. For example, once it erroneously placed a bunch of important files to a folder that was incorrectly named after a hidden temp file. [...] I know no file recovery software can perform miracles
Yes, you are absolutely right, it can happen. 😇 This is usually caused by inconsistent metadata. RecuperaBit doesn't really recreate the metadata, it just uses what is available to rebuild a reasonable directory structure.