Re: Adding linux_link(2) system call, second round

[christos%astron.com@localhost (Christos Zoulas)]

In article <1k5abxi.a8h289rm4jc3M%manu%netbsd.org@localhost>,
Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:
>Quick summary for the impatient: NetBSD link(2) first resolves symlinks
>before doing the actual link to the target. As a result, NetBSD link(2)
>fails on symlinks to directories or to non existent targets.
>
>On the other side, Linux link(2) is dumb and just create a second
>symlink with the same inode. Therefore it does not care about the
>symlink target, and will succeed even if it is a directory or if it is
>nonexistent. 
>
>Both behaviors are standard compliant, since SUSv2 says nothing about
>resolving symlinks or not. I found at least one program (glusterfs),
>which assumes the Linux behavior, and is a real pain to fix on NetBSD
>because of that.
>
>I proposed to implement a linux_link(2), or lazy_link(2), whatever
>sounds nicer. It seems it does not reach consensus, but I am not sure I
>understood why: what are the problems that would be introduced by adding
>such a system call? At least I can tell what benefit it would have: it
>would ease porting from Linux.

I don't have an issue with it as long as:
        - fsck does not get confused
        - filesystems don't need to be modified to support it
        - there is consensus that this is not harmful
        - I am also ambivalent about exposing this in the native abi
          because it will only cause confusion.

Also perhaps just call it link2(from, to, flags) in the long tradition
of adding a number to existing syscalls when extending them ;-)

christos