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 m...@netbsd.org
