A case for variant symlinks

... except that now you need to maintain the list of all parents through all operations. What's worse, you can't just stop at direct parents - you need traverse all chains of ancestors, however long they might be. With the unique chain to root you already have all of that in RAM - you either get them from pathname resolution, or you've started with fhandles and their decoding includes traversing the chain of ancestors until the damn thing is connected to the root. With multiple links you could very well have never seen the majority of those ancestors, which means that loop detection turns into massive IO. Now add the fact that you need to block all rename() (and link() to directories, and rmdir()) for the duration of that check, and it becomes _very_ unattractive. Locking is also less than pleasant. Once you add that to the costs of maintaining the crap attached to struct file, well...

It's not impossible that somebody would eventually come up with a decent way of doing that stuff. I've never been able to. Neither had *BSD folks. And Thompson, Pike et.al. flat-out decided that all that crap was just too much headache to bother with - even though they started their list of the bad ideas not to duplicate with cross-directory renames, overwriting renames, symlinks and fchdir. On very different VFS architectures, including the one designed pretty much from scratch, with freedom to drop the syscalls considered to be misfeatures. Which is something the rest of us couldn't afford - not without breaking arseloads of userland code.

Again, maybe there is a decent way of doing that just waiting for somebody to invent it. I would love to read it through and try to poke holes in it - got to be interesting. But until somebody does come up with something that survives peer review... Filesystem with multiple hardlinks to directories is a Bloody Bad Idea(tm). Sorry.