GNU bug report logs - #13447
ln "" foo gives misleading error message

Previous Next

Full log

Message #21 received at 13447 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 13447 <at> debbugs.gnu.org, Ken Irving <ken.irving <at> alaska.edu>
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Tue, 15 Jan 2013 10:31:28 +0100

Pádraig Brady wrote:

> On 01/15/2013 08:23 AM, Ken Irving wrote:
>> (Previously sent in error to the bug-gnu-utils list.)
>>
>> I've been using symbolic links in a non-file-related way, e.g., to store
>> arbitrary string values, 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
>>
>> 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
>>
>> 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?
>>
>> I only happened upon this in working on a test script, and have no
>> expectation for the operation to succeed.
>
> We're just reporting what the operating system returns here:
>
> $ python -c 'import os; os.symlink("","tl")'
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> OSError: [Errno 2] No such file or directory
>
> Interestingly I notice that solaris for example allows a NULL old_path.

That Solaris behavior is contrary to POSIX 2008
http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html

If someone is motivated, this suggests a symlink wrapper
in gnulib would be welcome: it would make it so even on
Solaris, symlink(any, "") would fail with the required ENOENT.

> I suppose we could handle this case specially like:
>
>   if (errno == ENOENT && !*old_path)
>     error(...,"An empty target is not supported on this system");

s/supported.*/portable|valid/?

> Though I'm not sure there's much benefit in a specific
> error message in this case?

I could go either way.
There is precedent, but it's such a corner case,
it may not be worth the added code.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.