Emmanuel Dreyfus <manu%netbsd.org@localhost> writes: > I was trying to track down a bug in glusterfs on NetBSD and encountered a > behavior difference between NetBSD and Linux. NetBSD will refuse (EPERM) > to link(2) on a symlink to a directory, while Linux is fine with such > an operation (but fails to link(2) directly to a directory, just like > NetBSD). > > A simple case showing the difference is below. Anyone has an opinion > about this? Who is standard compliant, and does it make sense to "fix" > our link(2) to match Linux? > > $ cd /tmp > $ mkdir i386 > $ ln -s i386 inst.xxx > $ ln inst.xxx machine > ln: machine: Operation not permitted > $ uname > NetBSD > > $ mkdir i386 > $ ln -s i386 inst.xxx > $ ln inst.xxx machine > $ ls -ld machine > lrwxrwxrwx 2 manu manu 4 jui 29 10:03 machine -> i386 > $ uname > Linux Posix says: http://pubs.opengroup.org/onlinepubs/009695399/functions/link.html which gives an implementation-dependent out. NetBSD appears to be compliant, and to follow the default/sane interpretation. Also, from POSIX, it seems that link on anything other than a regular file is irregular (except a symlink, where the link is made on the target, no different than any other operation). Also, NetBSD ln makes a link to the target of the symlink, which is what I would expect. $ touch foo $ ln -s foo bar $ ln bar baz $ ls -l foo bar baz lrwxr-xr-x 1 gdt ir 3 Jul 29 07:03 bar -> foo -rw-r--r-- 2 gdt ir 0 Jul 29 07:03 baz -rw-r--r-- 2 gdt ir 0 Jul 29 07:03 foo $ uname NetBSD On Linux, is a hard link to the symlink created for link on any symlink? Or is it to the file if the target is not a directory? ; $PWD and /tmp are on ffs and tmpfs $ touch /tmp/foo $ ln -s /tmp/foo bar $ ln bar baz ln: baz: Cross-device link What filesystem on Linux? Perhaps someone could check on solaris. All in all it seems like a bug for glusterfs to be using link this way.
Attachment:
pgpf3cEn96rNA.pgp
Description: PGP signature