Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I think there is some general confusion on the relation between all four of these items scattered throughout the web. I wanted to get this straightened out.

  1. Are named forks the same as extended attributes? If not, what are extended attributes?
  2. Is the resource fork still implemented as a fork or as an extended attribute? If it is implemented some other way, then how?
  3. The metadata stored with a file (creator, date modified...) is there any relation or overlap in terminology between the other three mentioned. An example would be, are extended attributes just extra metadata pairs (key + value) stored on a file.

Any answers that can clarify how all four of these are interrelated, especially regarding the three question would be greatly appreciated, and contribute to settling disputes I see occurring across different resources.

share|improve this question
    
For learning about HFS Plus: fileXray User Guide and Reference (PDF, 1.8 MB, 173 pages) is very useful. I'm a user of fileXray. Also: Technical Note TN1150: HFS Plus Volume Format is legacy, retired by Apple, but still useful for many purposes. –  Graham Perrin Dec 25 '12 at 7:00
add comment

2 Answers 2

up vote 5 down vote accepted

Confusion arises from the fact that the relationship between these concepts is complex and has changed over time. In current systems the difference between a named fork and an extended attribute is largely academic.

For an extended attribute, the actual data is stored in the attribute data record.

For a fork, what's stored is the list of disk allocation blocks that contain the data. A resource fork is still a fork.

Basic file system metadata is stored in dedicated elements of the file system record itself, independent of the attributes and named fork references.

share|improve this answer
    
But is an extended attribute actually stored as it's own fork, or is there a fork for extended attributes? How is it related in the most recent version of OSX? –  rubixibuc Feb 16 '12 at 20:27
    
I don't understand, when you say attribute do u mean "extended attribute." If so where is the attribute record kept. Is it stored as part of the file system structure HFS+ or is stored in some sort of database? Please respond to the first comment as well when you can. –  rubixibuc Feb 17 '12 at 4:10
2  
Sorry. I'm not here frequently and didn't see your follow-up questions until I came here looking for something else. An extended attribute is a named fork. I was using attribute as shorthand for "extended attribute." The attribute records are kept in a private part of the file system called the attributes tree. You could consider it a form of database. The data for each attribute may or may not be in that tree depending on how large it is. –  GregW Mar 21 '12 at 12:39
    
"… file system metadata is stored in dedicated elements of the file system record …" – instead, I'd probably say "… file metadata is stored in dedicated elements of the record for the file …" –  Graham Perrin Dec 25 '12 at 6:35
    
Maybe worth nothing that whilst com.apple.FinderInfo may appear as an extended attribute, Extended Finder Info (typically date_added, extended_flags plus three reserved fields) is not an extended attribute. –  Graham Perrin Dec 25 '12 at 6:46
show 1 more comment

I am not an expert on this, but I have read a bit to try to understand what is going on.

I would say "Confusion arises from the fact that:

  • the relationship between these concepts is complex and
  • has changed over time and
  • Apple have implemented both program level APIs and tools like ls or cp is such a way as to hide many of the differences between the concepts."

AIUI, the HFS+ Catalog file contains Catalog File Records (among other things). The Catalog File Record contains the normal sort of information about the file such as creation date, access date etc. The Catalog File Record also contains two structures that give information about the location and size of the data fork and of the resource fork.

AIUI, HFS+ also has (copied from Wikipedia HFS+) an "Attributes File [which] is a new B-tree in HFS Plus that does not have a corresponding structure in HFS. The Attributes File can store three different types of 4 KB records: Inline Data Attribute records, Fork Data Attribute records and Extension Attribute records. Inline Data Attribute records store small attributes that can fit within the record itself. Fork Data Attribute records contain references to a maximum of eight extents that can hold larger attributes. Extension Attributes are used to extend a Fork Data Attribute record when its eight extent records are already used."

AIUI, the data stored in (or referenced from) the Attributes File (whether inline, Fork Data or Extension Attributes) are known as Extended Attributes.

Those are the data structures, so how are they used?

AIUI, early versions of the operating system (possibly versions before 10.4 Tiger, which John Siracusa seems to indicate had some major changes in this area), pointed to the data fork and the resource fork from the Catalog file.

AIUI, once we get to 10.4 Tiger, the Attributes File becomes widely used to store all sorts of data.

It is possible (but I don't know) that in 10.4 and after, any Resource Forks are pointed to from the Attributes File. I.e. in answer to your first question, I would say named forks are Extended Attributes, unless they are the Resource Fork, and the Resource Fork is referenced from the Catalog file.

The problem in knowing how things are implemented is that in order to preserve backward compatibility, and probably particularly to support access to file systems written by one version of Mac OS from another version, different things and mixtures of things need to be supported transparently.

We can't tell from the normal Terminal command line tools where data is actually being held.

So, access to rsrc might suggest that the Resource Fork in the Catalog file is being accessed.

$ ls -l Icon^M/rsrc
-rwxr-xr-x  1 root  admin  486 23 Jul  2004 Icon?/rsrc

However, we know that although the syntax looks like a file below the Icon^M directory is being accessed, this is not really the case, because

$ ls -lR Icon^M
-rwxr-xr-x@ 1 root  admin  0 23 Jul  2004 Icon?

so Apple have implemented a special case for Resource Forks.

If instead we do

$ ls -l@
-rwxr-xr-x@ 1 root  admin   0 23 Jul  2004 Icon?
    com.apple.FinderInfo    32 
    com.apple.ResourceFork  486 

This suggests that we are accessing the Attributes File. But again, the implementation of ls may have a special case for Resource Forks.

John Siracusa points out here that the ACL lists are stored as 'Extended Attributes', but are specially masked out so they are not shown in xattr. So again there is special case processing in the implementation of xattr.

(Note that this special case processing may be in the code of the tool, or in the code of the underlying APIs that the tools access.)

GregW, if you see this, it would be nice to get a more expert opinion as to whether I am along the right lines, or just hopelessly confused.

share|improve this answer
    
There is also a discussion here, but I don't think that 'jonsview' is very helpful. –  Tim Jul 11 at 18:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.