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.

  • 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. Commented Dec 25, 2012 at 7:00
  • I had been thinking that extended attributes were implemented by means of named forks on HFS+ but that on APFS named forks are implemented by means of extended attributes. But the timeline makes that unlikely: Named forks were introduced with HFS+ in 1998 on Mac OS 8.1 and deprecated in 2013 with Mavericks. APFS was introduced in 2017 with High Sierra. Extended attributes came along in with Mohave in 2018. Commented Mar 9, 2021 at 4:42

2 Answers 2


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.

  • 1
    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
    Commented Feb 16, 2012 at 20:27
  • 1
    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
    Commented Feb 17, 2012 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
    Commented Mar 21, 2012 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 …" Commented Dec 25, 2012 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. Commented Dec 25, 2012 at 6:46

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.

  • There is also a discussion here, but I don't think that 'jonsview' is very helpful.
    – Tim
    Commented Jul 11, 2014 at 18:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .