[hfs-user] Identification of deleted files in HFS plus

Simon Bazley sibaz at sibaz.com
Wed Feb 8 07:21:36 PST 2006


Hi Rashmi,
                   It's been a while since I've looked at the HFS specs 
(incase you don't already have it, I'd reccomend getting "Inside 
Macintosh Files" By Apple, Addison Wesley (ISBN 0-201-63244-6)).  The 
only bit that I could find relating to deletion of the Trash, is page 
2-37 Deleting Files and File Forks, which gives the function prototypes 
to call to delete a file and explains that all the system does when you 
delete is "delete both forks of a bile by removing the catalog entry for 
the file and asjusting the volume information block and volume bitmap 
accordingly".  It also points out that "These functions do not actually 
erase the disk areas occupied" so you might be able to salvage the file. 
                   Anyway, answering your question, as each file (or 
directory) on disk is essential a node Id with a pointer to some Catalog 
Directory Data Record telling you where it is, I'd guess that files that 
are in the trash, simply point to some symbolic leaf file to indicate 
that status.  I'd assume you could look at a specific Data Record for a 
file before and after you put it in the trash and see what changes.  It 
could be that trash status is one of the Finder information flags, as 
otherwise I'm not use how the original directory location would be 
preserved (see pages 2-71 through 2-74 if you have no idea what I'm 
talking about). 

                   If the catalog record is actually deleted, I'm not 
sure what the system does.  I'd guess the system doesn't bother to 
actually wipe a disused catalog record, and just wipes some of it.  My 
first guess would be to set the cdrType value to 0 (cdrType is an enum 
in which only values 1-4 mean anything).  If that is the case you'd be 
able to find out which block of disk actually contains the original file 
and track it.  However as is always the case with deleted files, you 
should check each block in the allocation table as you follow it.  The 
deletion process says it zero's the relevant bits in the table so it's 
safe to say if a bit isn't zero it's been re-used already. 
                    The catalog record contains the ExtDataRec for the 
data and resource forks, so if the above is true, you're in luck, and 
you have the first 3 chunks of the data and resource forks.  As for the 
Extents Overflow Files, I'm not use how it handles deletions, I can't 
see any obvious way for it to mark a record as deleted without actually 
wiping it, but the book does imply similarities with the type of Node 
used in the main catalog, which does.  Under FAT each block of an actual 
file contains a reference somewhere to the next block. I'm not sure but 
if such a thing exists somewhere in HFS, but failing that I can't see 
how to recreate a deleted file in the absence of it's catalog and 
extents records.

                   Hope this helps,
                                               Simon

P.S. There is some comparison done in the HFS+ revision document between 
that and HFS (in particular it gives some details pictures relating to 
catalog and extent leaf format), that might give you a further insight, 
only I can't lay my hands on it now, so I can't tell you if it is useful. 

Rashmi M wrote:

>Hi All,
>
>	I am writing an application on Mac to list out the files deleted from the system (even from the trash). I have written code to read the catalog file node by node. But I have no idea of how deleted files are represented and how can I access them. Any guesses?
>
>Any input on this would be of great help.
>
>Thanks in advance.
>
>Best Regards
>Rashmi
>  
>




More information about the hfs-user mailing list