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.
