|
|
|
|
|
by Overdr0ne
1848 days ago
|
|
Yeah, not a fan of recursive directory trees. Sysfs for example is pretty wonky esp when you're searching for some specific attribute of the device. Not hard links or real files ftm, but same idea. Hard linked directories breaks the category system. Now the same name for a different inode in two directories is a point well taken, but I would argue that does not fully describe the inode, that name is just one component of the metadata for that file. People are just so unaware of all that other metadata because the interface rarely shows it to them. So many people have taken to packing all that data into the filename. Version numbers, code names- it's one way to achieve portability i guess, but what an ugly compromise! And with all the virtual environments now for pythons and such, it's quite easy to find yourself using the wrong version of something if you don't really know what you're doing and just look at the filename. Hard linking links all that metadata, which of course does include that unique ID that open returns, so I think it's okay. I would just like to see our file interfaces more adapted to showing all that important metadata in a comfier way |
|
There might be some way to muck around with that using attributes (at least in theory, I don't know of any that do this now), but presently, the only way to accomplish this is through workflow and integrity-checking systems (e.g., that "filename" at any of numerous specified points should be identical to and/or a hardlink of a specified canonical source).
Oh, and one more: since hardlinks apply only to a single filesystem, any cross-filesystem references are impossible.
I think you also end up with issues in almost all cases of networked filesystems: NFS, SSHFS, etc.