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

[Emmanuel Dreyfus <manu%netbsd.org@localhost>]

On Fri, Jul 29, 2011 at 07:10:33AM -0400, Greg Troxel wrote:
> On Linux, is a hard link to the symlink created for link on any symlink?

On Linux, it always work on the symlink itself, and it is coherent:
$ mkdir i386
$ ln -s i386 inst.xxx
$ ln inst.xxx machine
$ ls -lid i386 inst.xxx machine
1135692 drwxrwxr-x  2 manu manu 4096 jui 29 10:03 i386
1135697 lrwxrwxrwx  2 manu manu    4 jui 29 10:03 inst.xxx -> i386
1135697 lrwxrwxrwx  2 manu manu    4 jui 29 10:03 machine -> i386

$ touch foo
$ ln -s foo bar
$ ln bar buz
[manu@boulet tmp]$ ls -lid foo bar buz
1135704 lrwxrwxrwx  2 manu manu 3 jui 29 15:59 bar -> foo
1135704 lrwxrwxrwx  2 manu manu 3 jui 29 15:59 buz -> foo
1135702 -rw-rw-r--  1 manu manu 0 jui 29 15:59 foo

NetBSD fails (EPERM) on the first case and produce this for the second one:
# ls -ldi foo bar buz
5 lrwxr-xr-x  1 root  wheel  3 Jul 29 16:12 bar -> foo
4 -rw-r--r--  2 root  wheel  0 Jul 29 16:12 buz
4 -rw-r--r--  2 root  wheel  0 Jul 29 16:12 foo

> What filesystem on Linux?

This is plain ext3fs, but I suspect it does not depend on the
filesystem. On NetBSD, that behavior is hardcoded at the very
beginning of sys_link(), filesystems cannot interfere with it.

> All in all it seems like a bug for glusterfs to be using link this way.

Given the context, that will not be easy to fix and would have a performance
hit. This is a filesystem distributed using a distributed hash table, and
in order to avoid the issue, the client would have to resolve symlinks 
on its own, which implies a few transactions back and forth with servers.

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? If 
linux_link(2) seems unreasonable, it could be lazy_link(2), weak_link(2),
braindead_link(2) or whatever.

-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost