On Thu, 18 Jul 2024, 23:50 Jack Pugmire via Gcc-help, <gcc-help@xxxxxxxxxxx> wrote: > Thank you so much! This is exactly the kind of information I was looking > for. > > 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 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. > > If you have a filesystem hierarchy with no links or bind mounts, then it > forms a tree (rigorously, in graph theory terminology), which allows you > to make certain assumptions during traversal. As long as you ignore the .. and . directory entries. Symbolic links are clearly > distinguished from ordinary files, so we can add those and still do fast > traversal. 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. Most filesystems do not allow hard links to directories, so you can't have cycles (if you don't count the .. and . entries). I'm still admittedly in the very early stages of this > line of inquiry, but I believe it could have applications in functional > package managers like Guix and Nix. I have some ideas for fast traversal > with hard links, but it would be easier without. > > > If you want to have GCC optionally use symbolic links here, implement > > that, and send a patch? > This is a great idea. It would be perfect for my purposes. > > Thank again, > Jack >
