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