tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



On Jul 29, 2011, at 10:20 10AM, Emmanuel Dreyfus wrote:

> 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.
> 
Consider the following two sequences:

        a) Create a file A
        b) Create a symlink X->A
        c) Create a hard link Y=X
        d) Unlink a
        e) Create a directory A

or

        a) Create a symlink X-A', where A' doesn't exist
        b) Create a hard link Y=X
        c) Create a directory A

What should happen?  And why should A being a directory initially change the 
semantics
of X and Y, compared with the desired result of the first two scenarios?  (As 
best I
can tell, the first scenario does work on NetBSD and the second doesn't, at 
least when
using ln(1).)


                --Steve Bellovin, https://www.cs.columbia.edu/~smb







Home | Main Index | Thread Index | Old Index