The problem with multiple paths leading to the same file isn't with the file system, but with the file system users. When you're writing scripts or programs against file systems it is really convenient to assume that each filename is one and only one file, that the file has a unique name, and that the file system is strictly a tree.
File systems can technically break all of these; files can contain multiple files within themselves with many file systems, the ability to have multiple paths leading to the same file means that if you just have the file in hand you don't have a unique path, which also means that if you remove that name it doesn't mean you've removed the file. But most of the time, you can kinda get away with writing normal code and it'll do the right thing. But that last one really burns. It is really easy to write code assuming file systems are just trees, and in particular can't have infinite loops, and be wrong about that.
i make extensive use of hardlinks in my files (especially with photos), and i don't see the problem. if i remove a file, i don't usually want it gone completely, but i want removed from this particular location, if it is hardlinked elsewhere, i usually still want to keep it there.
if i want to really remove it, i can scrub the contents without removing the hardlink, and if i want to delete after scrubbing i check the hardlink count and search for the remaining entries.
Doesn’t a lot of software break hardlinks on edit? I think non-database software usually completely replaces the file via overwrite or atomic rename.
Sometimes you might want that behavior, but other times you might not. But there’s no option in any app I’ve seen to choose how to handle hardlinks on edit/save.
yes, i consider this a conceptual design flaw in unix. effectively i think a better way to do this would be if the move or copy operation onto an existing file would move/copy the content of that file onto the target inode. there could be a seperate rename operation which keeps the current behavior
fortunately in my case this issue is not a problem. i use hardlinks mainly for pictures where i never want to replace the original anyways, so editing always gets me a copy which i don't need to link to multiple places.
File systems can technically break all of these; files can contain multiple files within themselves with many file systems, the ability to have multiple paths leading to the same file means that if you just have the file in hand you don't have a unique path, which also means that if you remove that name it doesn't mean you've removed the file. But most of the time, you can kinda get away with writing normal code and it'll do the right thing. But that last one really burns. It is really easy to write code assuming file systems are just trees, and in particular can't have infinite loops, and be wrong about that.