[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)
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.
Main Index |
Thread Index |