AFAIK macOS is *nix based.
So basically when you "delete" a file subsystem only remove the inode reference to that file. that's a question of speed and efficency of possibly deleting hundreds of files.
As you remember everything is "file" in *nix, your directory is a file too.
As long as your system don't overwrite the disk space previously attached to the deleted file, you have a chance to recover.
*** BUT *** on active system the next millisecond the inode is "freed" the bigger the chance that those space get overwritten.
And a file / directory could have multiple extends over the entire disk, which further reduces the chance of recovering the entire deleted file(s).
On a loaded server with multiple processes / threads running in memory, chance = 0.
So sysadmin are right when they said recovery a deleted file is kind of miracle.
You have been very lucky, trust them.
unix.stackexchange.com
So basically when you "delete" a file subsystem only remove the inode reference to that file. that's a question of speed and efficency of possibly deleting hundreds of files.
As you remember everything is "file" in *nix, your directory is a file too.
As long as your system don't overwrite the disk space previously attached to the deleted file, you have a chance to recover.
*** BUT *** on active system the next millisecond the inode is "freed" the bigger the chance that those space get overwritten.
And a file / directory could have multiple extends over the entire disk, which further reduces the chance of recovering the entire deleted file(s).
On a loaded server with multiple processes / threads running in memory, chance = 0.
So sysadmin are right when they said recovery a deleted file is kind of miracle.
You have been very lucky, trust them.
what does a "deleted file" entry look like in the journal
I hope I've got this right: A file's inode contains data such as inode number, time of last modification, ownership etc. – and also the entry: »deletion time«. Which made me curio...
Last edited:
