[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Adding linux_link(2) system call, second round
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
>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 ;-)
Main Index |
Thread Index |