Re: Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> What about adding a linux_link(2) that would do exactly what link(2)
>> does but without the FOLLOW flag to NDINIT on the path argument?

How about just fixing link(2) that way?

>> If linux_link(2) seems unreasonable, it could be lazy_link(2),
>> weak_link(2), braindead_link(2) or whatever.
> You'll also need to update every filesystem to allow this and update
> all the various fsck programs to allow filesystems to be in this
> state.

Hardly.  The most that needs to be done to "every filesystem" is to
reject these operations.  The filesystem(s) that we want to support
hardlinks to symlinks can then be uptdated, one at a time, along with
their fscks.

> I'd disagree with this as it seems like a nonsensical thing to do.

Why?

I usually can understand your point of view, even when I disagree with
it, but this time I'm baffled.  What's nonsensical about hardlinking to
a symlink?  Two names pointing to the same inode, which inode happens
to be a symlink - I see nothing nonsensical about that.

Of course, some filesystems may not implement symlinks as (their analog
of) inodes; they presumably will refuse such attempts.  Again, nothing
nonsensical; pretty much everything about symlinks can potentially vary
with the filesystem; this is no different.

What am I missing?

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B