Re: Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)
> I seem to remember that once upon a time, the idea for symlinks was > that they were magic in some way, and would not have mode bits, > owner/group, etc. Not having a link count would fit with that. It would. A filesystem that implements symlinks that way would presumably refuse attempts to hardlink to a symlink. I don't think I've ever suggested that a filesystem should be unable to refuse such hardlink attempts; indeed, some filesystems don't do symlinks at all. >> (c) I've long thought there should be a way to update a symlink >> in-place. > Yes! I've been thinking about it ever since symperm went in. The write bit is unused, and it seems to me it would make sense for it to control the ability to update the link-to string in-place...but of course there's no way to do that quite aside from how permission to do it is controlled. (Though I suppose symlink(2) on an existing writable link could be made to do it. But I'm not sure if VOP_SYMLINK on an existing link should do it) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)
On Fri 29 Jul 2011 at 12:12:22 -0400, Mouse wrote: > (a) You're forgetting that symlinks have other attributes than the > link-to string. The most obvious is mode bits (which have no effect > unless you mount -o symperm, but (a1) that can be done and (a2) they > can be queried with lstat(2) even if the filesystem doesn't use them), > but there are others, such as owner, or even inumber. I seem to remember that once upon a time, the idea for symlinks was that they were magic in some way, and would not have mode bits, owner/group, etc. Not having a link count would fit with that. Not that I agree with it, because the implementation has always been different and makes sense in its own right (if not more). So I vote for allowing hard links to symlinks. > (c) I've long thought there should be a way to update a symlink > in-place. Yes! -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
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 manu4 jui 29 10:03 inst.xxx -> i386 > 1135697 lrwxrwxrwx 2 manu manu4 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
Re: Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)
>> FWIW, I just asked some linux guys about the linux behavior and the >> answer was "we sell rope". > That would be my answer too, though I'd probably phrase it as not > preventing you from doing stupid things because it would also prevent > you from doing clever things. (I know, replying to myself is bad form.) Perhaps most important, to me, is that "I can't think of a use for it" is a really bad reason to actively forbid an otherwise meaningful operation. Except as I noted, I can't think of a use for it either - but I am not confident it has no use, and I *definitely* am not sure enough nobody will ever find a use to think it's a good idea to actively forbid it. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)
>>> I'd disagree with this as it seems like a nonsensical thing to do. >> Why? > Because symlinks are a special type of filesystem object with their > own semantics Every filesystem object is. :) > Also, from a more operational standpoint, because there's no way to > update a symlink in place, so there's no difference between two > symlinks and two hard links to the same symlink except confusion and > the number of inodes used. (a) You're forgetting that symlinks have other attributes than the link-to string. The most obvious is mode bits (which have no effect unless you mount -o symperm, but (a1) that can be done and (a2) they can be queried with lstat(2) even if the filesystem doesn't use them), but there are others, such as owner, or even inumber. (b) If you have a lot of symlinks, inode usage may actually matter. (c) I've long thought there should be a way to update a symlink in-place. > FWIW, I just asked some linux guys about the linux behavior and the > answer was "we sell rope". That would be my answer too, though I'd probably phrase it as not preventing you from doing stupid things because it would also prevent you from doing clever things. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)
On Fri, Jul 29, 2011 at 11:17:46AM -0400, Mouse wrote: > >> If linux_link(2) seems unreasonable, it could be lazy_link(2), > >> weak_link(2), braindead_link(2) or whatever. > > You'll also need to update every filesystem to allow this and update > > all the various fsck programs to allow filesystems to be in this > > state. > > Hardly. The most that needs to be done to "every filesystem" is to > reject these operations. The filesystem(s) that we want to support > hardlinks to symlinks can then be uptdated, one at a time, along with > their fscks. Yeah, well, it adds up to the same thing. > > I'd disagree with this as it seems like a nonsensical thing to do. > > Why? Because symlinks are a special type of filesystem object with their own semantics and for many purposes they're often not even directly addressable. Also, from a more operational standpoint, because there's no way to update a symlink in place, so there's no difference between two symlinks and two hard links to the same symlink except confusion and the number of inodes used. FWIW, I just asked some linux guys about the linux behavior and the answer was "we sell rope". -- David A. Holland dholl...@netbsd.org
Re: Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)
>> 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? How about just fixing link(2) that way? >> If linux_link(2) seems unreasonable, it could be lazy_link(2), >> weak_link(2), braindead_link(2) or whatever. > You'll also need to update every filesystem to allow this and update > all the various fsck programs to allow filesystems to be in this > state. Hardly. The most that needs to be done to "every filesystem" is to reject these operations. The filesystem(s) that we want to support hardlinks to symlinks can then be uptdated, one at a time, along with their fscks. > I'd disagree with this as it seems like a nonsensical thing to do. Why? I usually can understand your point of view, even when I disagree with it, but this time I'm baffled. What's nonsensical about hardlinking to a symlink? Two names pointing to the same inode, which inode happens to be a symlink - I see nothing nonsensical about that. Of course, some filesystems may not implement symlinks as (their analog of) inodes; they presumably will refuse such attempts. Again, nothing nonsensical; pretty much everything about symlinks can potentially vary with the filesystem; this is no different. What am I missing? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: link(2) on a symlink to a directory fails
>> [link(2) on a symlink] > Posix says: > http://pubs.opengroup.org/onlinepubs/009695399/functions/link.html > which gives an implementation-dependent out. I assume you're talking about the wording for directories, but that's not the issue here. The question here isn't about linking to directories; it's about linking to symlinks. That the test case given fails on NetBSD because the symlink points to a directory is a red herring; the Linux behaviour doesn't link to a directory any more than the NetBSD one does - it links to a symlink. > NetBSD appears to be compliant, and to follow the default/sane > interpretation. Actually, to me the sane interpretation would be the Linux one. Why _shouldn't_ I be able to hardlink to a symlink? (Filesystem permitting, of course, as for anything involving symlinks.) > 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). I read "file" in that description as meaning, basically, "filesystem object". Otherwise, there'd be no need to explicitly mention the case where path1 names a directory, because it has to "[name] an existing file". /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)
On Fri, Jul 29, 2011 at 02:20:10PM +, Emmanuel Dreyfus wrote: > > 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. Huh? Why? Creating another symlink with the same contents should have the same effect; it'll use an additional inode, but that should be harmless. > 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. You'll also need to update every filesystem to allow this and update all the various fsck programs to allow filesystems to be in this state. I'd disagree with this as it seems like a nonsensical thing to do. -- David A. Holland dholl...@netbsd.org
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 manu4 jui 29 10:03 inst.xxx -> i386 1135697 lrwxrwxrwx 2 manu manu4 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
Re: link(2) on a symlink to a directory fails
Emmanuel Dreyfus 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. pgpS63UUow1Vq.pgp Description: PGP signature
Re: link(2) on a symlink to a directory fails
On Fri 29 Jul 2011 at 08:12:38 +, Emmanuel Dreyfus wrote: > 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). It seems that if you ln to a symlink, you actually link to the destination of it. There is a -h option for not following symlinks but it is for the target file, not the source file. I'm not sure this makes sense, and I seem to recall vaguely that this was changed in the last few years. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
link(2) on a symlink to a directory fails
Hello everyone 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 -- Emmanuel Dreyfus m...@netbsd.org
