Hi! On Tue, Jul 23, 2024 at 05:26:23PM +0100, Richard Earnshaw (lists) wrote: > On 19/07/2024 14:52, Segher Boessenkool wrote: > >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. Yes. So before GCC existed, but only slightly so; for a long time GCC had to deal with systems without it. And since it already can deal with the lack of symlinks, there is no real reasson to unsupport this (there are systems without support for it in use today, too!) > >>>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. Yup. My point is that name lookups are slow, relatively, even on Linux (that has optimised this to hell and back, it is 10x to 100x faster there than on othere OSes!) > >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. Many systems have 64k (2**16), most Linux fses have 4G (2**32). But POSIX requires only 8! Also a big number, but only relatively ;-) Many fses implement ".." as a hardlink to the parent dir, so I doubt any such systems have 8, but who knows :-) > 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. One thing that many programs use hard links for: they look at argv[0] to see what name they were executed as, and they change behaviour based on that. Often there are command-line arguments to do the same thing as well then. Nothing here is more efficient or fast really, but it is a cute, elegant trick :-) Segher
