Re: ln "" foo gives misleading error message

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 [email protected] 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