[sleuthkit-developers] [ sleuthkit-Bugs-2706862 ] Handle uninitialized mode bits in HFS+

[SourceForge.net <no...@so...>]

Bugs item #2706862, was opened at 2009-03-23 14:29
Message generated for change (Tracker Item Submitted) made by robjoyce
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2706862&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: File System Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Rob (robjoyce)
Assigned to: Nobody/Anonymous (nobody)
Summary: Handle uninitialized mode bits in HFS+

Initial Comment:
According to Apple TN1150 (http://developer.apple.com/technotes/tn/tn1150.html#HFSPlusPermissions), it's legal for the permissions structure to be uninitialized.  In the current SleuthKit trunk, the inode type never gets set in this case.  (In SleuthKit 3.0.1, hfs_dinode_copy actually throws an error when this occurs.)

The attached patch sets the inode type to directory or file as appropriate if it's initially empty (based on the catalog node type).  It also sets the owner UID and GID to 99 ("unknown"), which are what the Mac OS HFS+ implementation does when it sees uninitialized permission structures.  (You could reasonably argue SleuthKit shouldn't do the latter, although I think it's better than conflating root (UID/GID 0) versus "uninitialized".)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2706862&group_id=55685