Notes initially composed as a reply in the OSX for Unix mailing list
I hope this will give some clarification to those interested in how the Unix filesystem hangs together. What follows describes UFS. I think HFS and HFS+ must be similar and can probably be viewed the same way, but there are major differences in the detail. This description is based on some comments made by the instructor on my first Unix course in '83. His name is lost in the mists of time, but he was Edinburgh University staff IIRC.
The first disc filesystems were non-hierarchical. just like the original Mac floppy filesystem was. There was one directory and space for files. The area of disc called the directory was a sort of table, mapping filenames to disc sector addresses and maybe some metadata. The capability of having a sub-directory was a major advance, but creating one involved allocating a chunk of disc space that worked like the first one, but on some other contiguous bit of disc. Creating sub-directories was expensive in resources and discouraged. Navigating such filesystems was also expensive. Some systems only allowed one level of nesting.
Ken Thompson's Unix file system was revolutionary and brilliant. The view of it expressed here below has surprised some Unix people because they are introduced to it top-down rather than bottom-up. I don't know that this is how he saw it, or if this is purely a view in retrospect.
Ken created a two level filesystem. The base level is an old-type single directory filesystem with a chunk of disc for a directory and the rest for data. The files all have numeric names - as numbers, not as strings, and we call these 'inodes'. The directory we call the 'inode table'. All the sector allocation, timestamps, ownership etc. metadata is stored in the inode entries, or old-style directory entries.
The second level is a layer we view this through. Some of those files, which we call (Unix) directories contain mappings between filename strings and inode numbers. There is a file, known as the 'root directory', or '/', under a known inode, that is the entry point for our view. The whole file hierarchy that we see is laid out in the contents of those files that are referred to as directories from above, starting at '/'.
To make it work like that, we would have to refer to (say) the directory /usr as /usr/, because there is nothing in the contents of the /usr file to say it is a directory, so data was added to the inode to indicate that the type of the file is 'directory'. That just makes it foolproof.
All actual file 'open's are done to inodes - entries in the base directory. The routines that handle file opens by name call filename to inode lookup routines that follow the second layer data hierarchy to get the final inode.
This system allows any inode to be pointed to by any number of (Unix) directory entries, allowing 'hard links'. Because a hard link is a(nother) link to an inode, they have to be on the same filesystem, but there can be any number of them. See another recent post of mine for why we're not allowed to make hard links to directories.
Soft links were a later addition, in fact the first versions of Unix I administered didn't have them.
Normal soft links are just a (Unix) directory entry that points to an file whose inode says it is of type 'soft link'. The data in that file is a replacement pathname string. If that data starts with a '/', the part of the path traversed so far is replaced with the file content and filename to inode lookup starts again. If the data has no leading '/' or starts '../' the appropriate changes are made and the lookup continues.
Some systems also have a 'Fastlink' implementation of soft links where, if the link data is small enough, it replaces the allocation data within the inode. This reduces the number of disc reads to do a lookup.
