[COFF] [TUHS] Re: History of cal(1)?

[Dan Cross via COFF]

On Fri, Sep 26, 2025 at 6:48 PM Bakul Shah <bakul at iitbombay.org> wrote:
> On Sep 26, 2025, at 7:26 AM, Dan Cross via COFF <coff at tuhs.org> wrote:
> > A random thought: some versions of UFS have support for something they
> > call "fast symlinks".  Symbolic links, of course, are just files that
> > contain a string naming some other file, and if a pathname has a
> > component naming a symlink when walked by `namei`, that string is
> > substituted for the name of the symlink.  But often these names are
> > very short, and recall that the `inode` contains some space for disk
> > block addresses (60 bytes in UFS on 4.1C, but this got bigger in later
> > versions).  The idea with fast symlinks is that, if the target file
> > name of a symlink is short enough, the system can just store it in the
> > space that would normally be used for block addresses; there's no need
> > to allocate a separate fragment from a disk block, let alone bear the
> > cost of allocating a buffer and fetching a block from disk, if a short
> > name can be written directly into the inode.
>
> Storing symlink or small file content in the inode breaks unix
> semantics: whether you can hard link to a file would depends
> on its size!

I don't see why? A hard link is just a directory entry that points to
an inode; regardless of whether or not the file's data is in the inode
or in another block, the inode is still an inode, and the inode
continues to track metadata like link counts. As far as links are
concerned, placement of the file's data is irrelevant.

If you tried to inline file data into a directory, on the other hand....

        - Dan C.