How to recover entire directory of files

[korthout]

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 directory
• drat-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 file
• drat-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.

[jivanpal]

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.