How to recover entire directory of files
korthout opened this issue ยท 1 comments
First off, what a great tool ๐ Thanks for building this! I'm trying to recover a set of files from a dead external drive. I was already able to use it to recover the most important files individually. ๐
Currently I'm using the latest released version drat-0.1.3
. With it I'm able to recover single files, but not directories of files. The documentation seems to direct me to use --output
for this, but 0.1.3
doesn't seem to support this yet.
What I've tried so far:
drat-0.1.3-darwin-amd64 list /dev/disk3 0 /path_to_the_directory/
shows the files in the directorydrat-0.1.3-darwin-amd64 recover /dev/disk3 0 /path_to_the_directory/a_file >> /recovery/a_file
correctly copies the file's contents into the new filedrat-0.1.3-darwin-amd64 recover /dev/disk3 0 /path_to_the_directory >> /recovery_dir/
prints the same list of files as above, but ends with[1] 79239 segmentation fault drat-0.1.3-darwin-amd64 recover /dev/disk3 0
I thought about grepping the output of list to find the specific filenames to recover them iteratively in a script, but the output cannot be piped.
Any help would be appreciated.
Hi, the docs you're referring to describe planned functionality for version 0.2, which is not yet released. I am now employed full-time, hence not having been continuing development much, but this will hopefully ramp up within the next couple of weeks as I should have some time on the weekends.
I thought about grepping the output of list to find the specific filenames to recover them iteratively in a script, but the output cannot be piped.
This is just because the output is printed on stderr rather than stdout on v0.1.3 and earlier, so you can just redirect it with 2>&1
at the end of the command, then pipe that, e.g. drat list /dev/disk0s2 0 /Users/ 2>&1 | grep john
. However, you may like to refer to this Python script someone else created that already does this job of recursively recovering entire directories (albeit it uses the old apfs-list
command rather than the current drat list
one, so some syntax may be different).
[Trying to recover a directory results in a segfault.]
Thanks for pointing this out, this is currently undefined behaviour I hadn't considered. I'll try to address this in the next release.