Added file recovery and timeline generation functionalities

[TurtleARM]

No description provided.

[jivanpal]

Wow, thanks a ton for taking the time to create and provide this! To make sure I understand what the intent is here:

timeline takes a path to a directory in the first APFS volume (ignored? We always just scan the entire disk?), and just prints out a list of filenames and the chosen timestamp for them.

dumpfiles takes a path to a directory in the first APFS volume (ignored? We always scan from the volume's root, /?), a location to store recovered files, and then stores all recovered files in that location. Does it put the recovered files in the corresponding directory, or just put them at the root of the recovery directory? For example, if I do drat dumpfiles /Users/john /Users/john/RECOVERY, does this store the file /Users/john/Desktop/file-to-recover.txt at:

1. /Users/john/RECOVERY/file-to-recover.txt; or
2. /Users/john/RECOVERY/Desktop/file-to-recover.txt; or
3. /Users/john/RECOVERY/Users/john/Desktop/file-to-recover.txt; or
4. somewhere else?

I'm guessing it's (3) since the specified path within the APFS volume is ignored?

The dumpfiles functionality is slated to be added to recover soon, so I will likely review this properly and incorporate some of your code at that time. As for timeline, it seems interesting/useful in extremely dire situations and/or for forensics, so I'll probably clean it up and merge it after everything else I've got planned for v0.2 is sorted.

If any of the above is incorrect or bears clarification, please do so — thanks again!

[TurtleARM]

Wow, thanks a ton for taking the time to create and provide this! To make sure I understand what the intent is here:

No problem, it was a lot of fun learning APFS through this project!

timeline takes a path to a directory in the first APFS volume (ignored? We always just scan the entire disk?), and just prints out a list of filenames and the chosen timestamp for them.

It scans the entire disk image to find all the intact Volume Superblocks, then it navigates to the input directory and parses the timestamps. The final metadata struct should contain timestamps for every retrievable file version in that directory.
I agree that it should start from the input directory, for now it just traverses the FS tree from the root node one directory entry at a time until it finds the first non-Directory Record (which corresponds to the first file in the input directory).

dumpfiles takes a path to a directory in the first APFS volume (ignored? We always scan from the volume's root, /?), a location to store recovered files, and then stores all recovered files in that location. Does it put the recovered files in the corresponding directory, or just put them at the root of the recovery directory? For example, if I do drat dumpfiles /Users/john /Users/john/RECOVERY, does this store the file /Users/john/Desktop/file-to-recover.txt at:

1. /Users/john/RECOVERY/file-to-recover.txt; or
2. /Users/john/RECOVERY/Desktop/file-to-recover.txt; or
3. /Users/john/RECOVERY/Users/john/Desktop/file-to-recover.txt; or
4. somewhere else?

I'm guessing it's (3) since the specified path within the APFS volume is ignored?

Because of time restrictions, all files end up in the same output directory (option 1), but ideally they should be stored in a more appropriate path (local_path + remote_path).

The dumpfiles functionality is slated to be added to recover soon, so I will likely review this properly and incorporate some of your code at that time. As for timeline, it seems interesting/useful in extremely dire situations and/or for forensics, so I'll probably clean it up and merge it after everything else I've got planned for v0.2 is sorted.

Cool, timeline was especially thought for forensic purposes, thank you for sharing drat!