On 01/15/2013 09:31 AM, Jim Meyering wrote:
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
The POSIX ENOENT description only mentions the empty path2 case.
I.E. the empty symlink name, which as expected would return ENOENT.
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.
given the confusion above, it might be worth the
clarification error message.
thanks,
Pádraig.
