On 19/07/2024 14:52, Segher Boessenkool wrote:
Hi!
On Thu, Jul 18, 2024 at 03:48:38PM -0700, Jack Pugmire wrote:
In my experience I only rarely interact with hard links. GCC is a
project I hold in very high regard, so I was curious to see if there
was a strong reason to use one or the other.
Hard links are somewhat out of vogue. There is no reason for that, it
is mostly people not being familiar with it these days.
At one time only hard links were supported on Unix platforms. Soft
links were (apparently) introduced in BSD 4.1a.
Hard links are faster. Hard links are more efficient.
I figure that dereferencing a symbolic link (at least to a file on the
same physical disk) will be orders of magnitude faster than almost
anything you'd want to do with g++ once you find the inode.
Accessing a file via a symbolic link is *two* name lookups. A name
lookup costs as much as reading 100kB, or so.
At a minimum. Firstly the links may point to other links (there's a
limit to prevent infinite recursion), but each indirection costs another
lookup in the directory system. Secondly, long link names cannot be
stored in the directory structure itself (there isn't enough space), so
another block has to be read from somewhere to get the full path name.
Accessing a file via a hard link is exactly as costly as accessing a
file "normally": it *is* the normal way to read a file, after all! You
just have multiple path names resolving to the same inode, but this
changes nothing.
There's a large, but finite, limit to the number of hard links that a
file can have (the count has to be stored in the file's inode). There's
no limit to how many symbolic links can point to the same file, but see
above about recursion.
Soft links can dangle if the original file is removed. With hard links
you have to overwrite the original inode if you want all linked files to
see the new version; with soft links they will always pick up the
current version of the file.
Finally, of course, hard links can only exist within a single filesystem
mount, cross mount-point links cannot exist. Soft links are not
restricted in this way.
Generally speaking, however, soft links are a more powerful user-level
concept, but hard links are a more efficient system level concept. You
pays your money and you makes your choice.
R.
PS a slightly confusing thing about hard links (technically it's not
links) can occur in versioned (eg log-structured) filesystems: snapshots
of a file can have the same inode number but have different content.
This can confuse some tools even today which inspect the inode number
before doing a operation and they may refuse the operation because the
inode number is unchanged.
To the best of my understanding, hard links on the other hand
require us to keep track of all inodes with link count >1, so we can
detect cycles.
No, there is no such requirement. If you want to not duplicate files
that exist as multiple names, you keep track of the inode with all files
(like in "ls -i"), and that is all you need to do. Things like "tar" do
this.
Segher
