tag 13447 + notabug
close 13447
thanks
Ken Irving wrote:
> (Previously sent in error to the bug-gnu-utils list.)
Sending it to bug-gnu-utils was of course perfectly fine since "ln" is
one of the GNU utils and that is a good mailing list for all of the
utils as a general catchall. I even answered your question there.
That was all perfectly fine.
However after having had an answer there and having read it sending it
here to bug-coreutils (every email here opens a bug ticket) was not
good since it isn't the coreut...@gnu.org list you were directed to
for discussion. And of course you already had an answer that it was
in the kernel domain not the "ln" domain. So I am not sure what
answer you are expecting to be different asking the same question
again. Apparently you didn't like my answer. (shrug)
> 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 only happened upon this in working on a test script, and have no
> expectation for the operation to succeed.
In the future if you are looking for general discussion please
consider posting to the coreut...@gnu.org mailing list which exists
for general discussion of the coreutils project. Messages there won't
open a bug ticket and won't be tracked in the bug tracking system.
Note that just because I closed the bug ticket doesn't mean that
discussion can't continue here. It just means that this bug ticket
won't show up in the list of open bugs. Now that the ticket has been
created feel free to continue discussion here with replies to the bug
ticket.
Bob
