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. > > 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. 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. > 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
