I'm getting this on inspect:

[chriskuku]

Reading the Ephemeral objects used by this checkpoint ... OK. Validating the Ephemeral objects ... FAILED. An Ephemeral object used by this checkpoint is malformed. Going back to look at the previous checkpoint instead. END: Handling of this case has not yet been implemented. $

Would there be a chance that you can handle this case?

[jivanpal]

Hey, sorry for the wait, try git checkout ignore-ephemerals and recompile, feel free to reply/reopen if that doesn't help you out.

[chriskuku]

Thanks. Sorry for being late from my side again. Being not so familar with git, I did a git checkout ignore-ephemerals while sitting in the directory ~/Downloads/drat. Was that ok?

Did a make clean; make and started

sudo ./drat inspect --container /dev/disk2s2

again. It ends up in the same message.

NB: got this:

The file-system tree root for this volume has Virtual OID 0x404.
Looking up this Virtual OID in the volume object map ... corresponding block address is 0xab2b0.
Reading ... validating ... FAILED.
Going back to look at the previous checkpoint instead.
END: Handling of this case has not yet been implemented.
$ 
$ git status
On branch ignore-ephemerals
Your branch is up to date with 'origin/ignore-ephemerals'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    inspect.txt

nothing added to commit but untracked files present (use "git add" to track)
$ git add inspect.txt
$ git status
On branch ignore-ephemerals
Your branch is up to date with 'origin/ignore-ephemerals'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    new file:   inspect.txt

$ 

[jivanpal]

I did a git checkout ignore-ephemerals while sitting in the directory ~/Downloads/drat. Was that ok?

Yes, that's what you needed to do :slightly_smiling_face:

The file-system tree root for this volume has Virtual OID 0x404.
Looking up this Virtual OID in the volume object map ... corresponding block address is 0xab2b0.
Reading ... validating ... FAILED.

That is unfortunate... If Drat had better support for exploring past APFS transactions/checkpoints, or indexing the entire APFS container, then we could work from there, but as it stands, it doesn't, and I'm afraid I'm not in a position to work on Drat for any significant amount of time at the moment in order to implement that. Hopefully that will change within the next 6–12 months, but it seems unlikely.

Very sorry that I can't be of more help right now!

[chriskuku]

Thanks anyway. Possibly I'll overwrite the 5TB disk now and forget about that. I remember having tried with some other recovery tool under ventura and I was at a point to enter the decryption passwd and it didn't accept that password string. Maybe the fact that it has been encrypted is the main problem. Sorry for my ignorance :)