[TUHS] Quick Question: Early Filesystems and Name/Metadata Separation?

[Dan Cross via TUHS]

On Tue, Sep 16, 2025 at 2:15 AM George Michaelson via TUHS
<tuhs at tuhs.org> wrote:
> Is the return of a stat() call from the directory block not file "metadata"?

As Noel pointed out, there's no real metadata in the directory entry
itself.  The directory entry is really just a pair, consisting of a
string (the path name component in the entry) and an inode number.
Critically, the inode is stored separately, and holds all of the
metadata describing a file.  So while `stat()` may take a file name as
an argument, internally the kernel uses that to look up the associated
inode and populates the structure it returns from _that_, not from the
directory entry.

But as usual, it's slightly more complicated than that: on the PDP-11
Unix directory entries were fixed size: 16 bytes; 2 bytes for the
inode number (interpreted as an unsigned 16-bit integer) and 14 for
the file name part.  Working with these is incredibly simple.  But
Berkeley expanded this a bit with UFS, allowing 4 bytes (interpreted
as an unsigned 32-bit integer) for the inode number and up to 255
characters for the file name.  But since most file names were
well-short of 255 characters, storing them as such was wasteful, so
they added two other fields: a record length and a name length.  This
enabled them to compress entries down to a minimal record size,
aligned to a 4-byte boundary, and thus pack entries together rather
more tightly than if the entire 256 bytes (255 + 1 for the terminating
NUL byte) were stored directly.  Lookups---the most common
operation---remained simple: to retrieve the "next" entry in a
directory, one need only add the offset from the current entry to that
entry's position relative to the start of the directory file, but that
was an extra step compared to what workaday programmers were used to
doing (which was just opening the directory file read-only and, well,
reading from it), so the `opendir`/`readdir`/`closedir` interfaces
were added to hide this in the kernel and mimic the more traditional
open/read/close loop.

Unfortunately, adding and removing entries became significantly more
complex than in earlier file system versions.  Regardless, the
additional data added to directory entries are really more details of
the implementation of directories themselves, and not metadata about
the file an entry points to.

        - Dan C.

> On Tue, 16 Sept 2025, 2:21 pm Tom Perrine via TUHS, <tuhs at tuhs.org> wrote:
> > I think that was also true of Multics.
> >
> >
> > On Mon, Sep 15, 2025 at 5:30 PM Noel Chiappa via TUHS <tuhs at tuhs.org>
> > wrote:
> >
> > >     > From: Warren Toomey
> > >
> > >     > Was Unix the first to separate a file's name from the other file
> > > metadata
> > >
> > > UNIX was the first filesystem I know of where file metadata was not kept
> > in
> > > the directory. So, yes.
> > >
> > >         Noel
> > >
> >