2 ms·
Hard links don't have a canonical name though - they're all equally the same file, and this is really a problem: opening and editing a file in one location, edi
by XorNot 4y ago
Hard links don't have a canonical name though - they're all equally the same file, and this is really a problem: opening and editing a file in one location, edits it in all of them without you knowing what those locations might be.
Symlinks at least explicitly declare the dependency and how it should mutate.
A classic being /etc/resolve.conf symlinks - if I'm untarring and restore a symlink for it, I'm currently saying the file should have content from somewhere else on the system - not that the file is specific content.
- masklinn 4y ago> Hard links don't have a canonical name though - they're all equally the same file, and this is really a problem: opening and editing a file in one location, edits it in all of them without you knowing what those locations might be. That is something the filesystem could store tho, in the same way it stores the number of links to a file it could be a bit more capable and store the links themselves (possibly in a xattr). > Symlinks at least explicitly declare the dependency and how it should mutate. They only declare one dependency one way, it's not like a symlink gives you all the other symlinks to the terminal location it will affect.
- GoblinSlayer 4y agoSymlinks do that too even inevitably: no matter how you change the file, it changes at all links and you can't prevent it; systemd uses this feature when it creates dependency references (the linked dependency must never differ from the source, what hard links don't ensure).
- XorNot 4y agoThe difference is a symlink at least declares this explicitly. A hard link on the other hand looks and works like an independent file...but isn't one.