Brendan wrote:
No. The intuitive behaviour is that the file system is a hierarchical tree (without idiotic "one way teleportation traps" waiting for unsuspecting victims that appear and disappear as symbolic links are created, modified and removed); and people spent a lot of effort to make "cd" behave as people expect despite the fact that the underlying "chdir()" is a crippled joke designed by incompetent fools that cared more about their own convenience than the pain and complexity they were creating for everyone else.
It's "two way teleportation portals" that break the hierarchy. One way teleportation traps at least don't break the expectation that the file system is a tree. With two way teleportation portals, the "canonical descendant of" property is no longer a partial order of files, which ia exactly what we expected from a hierarchy.
Brendan wrote:
Note that nothing I have said in this entire topic (and as far as I can remember, nothing I have ever said on these forums ever) has involved hard links.
Well, you did not name them. Two way teleportation portals
are hard links (at least, their expected behavior with respect to VFS inode lifetimes and path resolution is the same). Call them whatever you want - the problems that I wrote about remain.
Brendan wrote:
A traditional UNIX system should continue being a crippled, broken and idiotic joke; because actually fixing problems, improving anything, and doing things properly would break compatibility (and because compatibility is the only reason Unix exists). My suggested fix is to throw Unix in the trash where it belongs so that future generations of people don't have to suffer.
Sure, throw throw away UNIX. But that was not the point of my question. What do you replace the UNIX path resolution with? Demand that every file system has to do multi-versioning in 2017? That answer is a bit simplistic, isn't it?
---
Actually, I put some more thought into this and I think that hard link-like (two way teleportation portal) behavior can actually be supported sanely. Replace them by "bind links" that perform spontaneous bind mounts which only stay valid while there is a reference (i.e. a process' working directory or a file descriptor etc.) to a file behind the bind mount. Detach the bind mount from the file system if the link is modified, renamed or removed.
This sometimes leaves processes in unreachable views of the file system and breaks the canonical order but does not suffer from the lifetime problems real hard links suffer from. It might actually be useful in some situations but is by no means a replacement for real symlinks aka one way teleportation traps.