[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ln "" foo gives misleading error message
From: |
Ken Irving |
Subject: |
Re: ln "" foo gives misleading error message |
Date: |
Mon, 14 Jan 2013 23:52:42 -0900 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Mon, Jan 14, 2013 at 11:56:32PM -0700, Bob Proulx wrote:
> Ken Irving wrote:
> > I've been using symbolic links in a non-file-related way, e.g., to store
> > arbitrary string values,
>
> Sure. This is done by many programs. Such as Emacs and Firefox for
> example which both store lock information. And others too. It is
> quite a commonly done technique.
>
> > but find that if I try to create a symlink with an empty 'target'
> > name, e.g., as 'ln -s "" foo', the error message emitted is not
> > really correct.
> >
> > $ ln -s "" foo
> > ln: creating symbolic link `foo' -> `': No such file or directory
> > $ ln -sf "" foo
> > ln: creating symbolic link `foo' -> `': No such file or directory
>
> That error message comes from the kernel. I agree that it isn't
> really correct. But if that is to be improved it would need to be the
> kernel that would need to improve it.
>
> I ran it with strace to report what the kernel returned.
>
> $ strace -v -e symlink ln -s "" foo
> symlink("", "foo") = -1 ENOENT (No such file or
> directory)
> ln: creating symbolic link `foo' -> `': No such file or directory
>
> It can be seen the "ln" program is simply reporting what the kernel
> returned to it as errno. The kernel returned -1 indicating failure
> and set errno to ENOENT as to why.
>
> > A link can be created when no file or directory exists, e.g.,
> >
> > $ stat x || ln -s x foo && echo ok
> > stat: cannot stat `x': No such file or directory
> > ok
>
> That is just fine. The value of the symlink can be an arbitrary
> value. Although I admit I didn't know it couldn't be a zero length
> string until you mentioned it. I only tested the Linux kernel. I now
> want to test other kernels. In particular BSD would be the gold
> standard reference for symlinks since they were developed there.
>
> > so it seems that 'No such file or directory' must not be the actual
> > reason for the failure. Perhaps something like 'null target name'
> > would be more accurate?
>
> On first thought I think it should be allowed. Although it is an
> unusual use to store nothing there. How would that be interpreted as
> a file? Would it be the same as "."? Perhaps the kernel authors were
> simply avoiding that question of defining what to do with a zero
> length value for the symlink. Allowing it may open more problems than
> they wanted to deal with and simply using ENOENT perhaps the simplest
> error to return in that case.
I don't have any particular reason to want to store a zero-length value,
but just found the error message message misleading, especially after
working with lots of 'bad' or 'dangling' symlinks which behave just fine.
> > I only happened upon this in working on a test script, and have no
> > expectation for the operation to succeed.
>
> Posting this here in bug-gnu-utils is of course good. However just
> for reference the "ln" program is part of the coreutils project. If
> you would like to discuss this with the coreutils developers directly
> (since only a few of them are subscribed here) the discussion list for
> it would be the address@hidden mailing list.
Oops. I did see that it was in the coreutils package, but somehow
got off track to post here after a bit of googling. I resent the same
message there, but not sure if I should cc this reply there as well...
Thanks for your help in digging into this.
Ken
--
Ken.Irving