[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13447: ln "" foo gives misleading error message
From: |
Jim Meyering |
Subject: |
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.
- bug#13447: ln "" foo gives misleading error message, Ken Irving, 2013/01/15
- bug#13447: ln "" foo gives misleading error message, Pádraig Brady, 2013/01/15
- bug#13447: ln "" foo gives misleading error message,
Jim Meyering <=
- bug#13447: ln "" foo gives misleading error message, Bob Proulx, 2013/01/15
- bug#13447: ln "" foo gives misleading error message, Bernhard Voelker, 2013/01/15
- bug#13447: ln "" foo gives misleading error message, Jim Meyering, 2013/01/15
- bug#13447: ln "" foo gives misleading error message, Eric Blake, 2013/01/15
- bug#13447: ln "" foo gives misleading error message, Geoff Clare, 2013/01/15
- bug#13447: ln "" foo gives misleading error message, Joerg Schilling, 2013/01/16
- bug#13447: ln "" foo gives misleading error message, Paul Eggert, 2013/01/16
- bug#13447: ln "" foo gives misleading error message, Eric Blake, 2013/01/17
- bug#13447: ln "" foo gives misleading error message, Pádraig Brady, 2013/01/15
- bug#13447: ln "" foo gives misleading error message, Jim Meyering, 2013/01/15