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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13447 in the body.
You can then email your comments to 13447 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Ken Irving <ken.irving <at> alaska.edu>
To: bug-coreutils <at> gnu.org
Subject: ln "" foo gives misleading error message
Date: Mon, 14 Jan 2013 23:23:12 -0900

(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.

Thanks

Ken Irving

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

From: Bob Proulx <bob <at> proulx.com>
To: Ken Irving <ken.irving <at> alaska.edu>
Cc: 13447 <at> debbugs.gnu.org
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Tue, 15 Jan 2013 02:16:31 -0700

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 coreutils <at> 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 coreutils <at> 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

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Ken Irving <ken.irving <at> alaska.edu>
Cc: 13447 <at> debbugs.gnu.org
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Tue, 15 Jan 2013 10:17:22 +0100

On 01/15/2013 09: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.
> 
> Thanks
> 
> Ken Irving

Thanks for the report, however this particular issue has previously
dicussed:
http://lists.gnu.org/archive/html/coreutils/2012-11/msg00008.html

The problem is that some coreutils programs do handle this special
case - i.e. "" as argument for file names - while others do not.
But no-one came up with patches to fix it yet - including me ;-)

Have a nice day,
Berny

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Ken Irving <ken.irving <at> alaska.edu>
Cc: 13447 <at> debbugs.gnu.org
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Tue, 15 Jan 2013 09:20:47 +0000

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.
I suppose we could handle this case specially like:

  if (errno == ENOENT && !*old_path)
    error(...,"An empty target is not supported on this system");

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

thanks,
Pádraig.

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.

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

From: Bob Proulx <bob <at> proulx.com>
To: 13447 <at> debbugs.gnu.org
Cc: Ken Irving <ken.irving <at> alaska.edu>
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Tue, 15 Jan 2013 02:44:37 -0700

Jim Meyering wrote:
> Pádraig Brady wrote:
> > 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

Where does it say this?  I read it through in detail but I didn't see
that it required a diagnostic to be emitted in the case that value is
am empty string.  What did I miss?

Bob

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>
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 09:53:22 +0000

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.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Bob Proulx <bob <at> proulx.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:55:00 +0100

On 01/15/2013 10:44 AM, Bob Proulx wrote:
> Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> 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
> 
> Where does it say this?  I read it through in detail but I didn't see
> that it required a diagnostic to be emitted in the case that value is
> am empty string.  What did I miss?

Right, the only 3 statements about path1 are:

 * The string pointed to by path1 shall be treated only as a
   character string and shall not be validated as a pathname.

 * [ENAMETOOLONG]
   [...] or the length of the path1 argument is longer than {SYMLINK_MAX}.

 * [...] in fact, the file named by the path1 argument need not exist
   when the link is created.

I'd read this as:
a) there can be any character in the string but a NULL (obviously).
b) the maximum length is limited to SYMLINK_MAX.
Nothing more.

BUT:
Some CU tools already catch zero-length file names (du and wc),
and a comment in the code states that FTS has problems with it
[src/du.c:1043]:

     /* Report and skip any empty file names before invoking fts.
         This works around a glitch in fts, which fails immediately
         (without looking at the other file names) when given an empty
         file name.  */


Have a nice day,
Berny

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

From: Jim Meyering <jim <at> meyering.net>
To: Bob Proulx <bob <at> proulx.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:58:36 +0100

Bob Proulx wrote:
> Jim Meyering wrote:
>> Pádraig Brady wrote:
>> > 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
>
> Where does it say this?  I read it through in detail but I didn't see
> that it required a diagnostic to be emitted in the case that value is
> am empty string.  What did I miss?

Oh!  You're right.  Thanks for pointing that out.
It's only the source (2nd argument) to symlink that may not
be the empty string.

  ERRORS

      These functions shall fail if:

      [EACCES]
      ...
      [ENOENT]
          A component of path2 does not name an existing file or path2 is
          an empty string.

There is no restriction on "path1".

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

From: Eric Blake <eblake <at> redhat.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 13447 <at> debbugs.gnu.org, Ken Irving <ken.irving <at> alaska.edu>,
	Austin Group <austin-group-l <at> opengroup.org>, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Tue, 15 Jan 2013 07:15:23 -0700

[Message part 1 (text/plain, inline)]

[adding the Austin Group]

On 01/15/2013 02:58 AM, Jim Meyering wrote:

>>> That Solaris behavior is contrary to POSIX 2008
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
>>
>> Where does it say this?  I read it through in detail but I didn't see
>> that it required a diagnostic to be emitted in the case that value is
>> am empty string.  What did I miss?
> 
> Oh!  You're right.  Thanks for pointing that out.
> It's only the source (2nd argument) to symlink that may not
> be the empty string.

I also checked POSIX 2008 TC1 (in the middle of ratification process),
and while it altered the wording, it still mentions only path2:

On Page: 2058 Line: 65095 Section: symlink()
In the ERRORS section, change the [ENOENT] error from:
[ENOENT] A component of path2 does not name an existing file or
path2 is an empty string.
to:
[ENOENT] A component of the path prefix of path2 does not name an
existing file or path2 is an empty string.
[ENOENT] or [ENOTDIR]
The path2 argument contains at least one non-<slash> character and ends
with one or more trailing <slash> characters. If path2 names an existing
file, an [ENOENT] error shall not occur.
Rationale: Austin Group Defect Report(s) applied: 146,428,436.
See http://austingroupbugs.net/view.php?id=146
See http://austingroupbugs.net/view.php?id=428
See http://austingroupbugs.net/view.php?id=436

What do others on the Austin Group think about an empty string for path1
in symlink()?  Current Linux rejects the symlink() call with ENOENT;
FreeBSD 8.2 allows it but refuses to resolve the symlink ("ln -s '' a &&
ls a/" reports ENOENT); Solaris 10 allows it and resolves the symlink as
though it were '.' ("ln -s '' a && ls a/" reports the current directory
contents).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #39 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 15:27:48 +0100

Pádraig Brady wrote:
...
>> 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.

Yes, I've demonstrated that rather well ;-)

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

From: Geoff Clare <gwc <at> opengroup.org>
To: Austin Group <austin-group-l <at> opengroup.org>
Cc: 13447 <at> debbugs.gnu.org, Ken Irving <ken.irving <at> alaska.edu>,
	Jim Meyering <jim <at> meyering.net>, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Tue, 15 Jan 2013 15:49:21 +0000

Eric Blake <eblake <at> redhat.com> wrote, on 15 Jan 2013:
>
> [adding the Austin Group]
> 
> On 01/15/2013 02:58 AM, Jim Meyering wrote:
> 
> >>> That Solaris behavior is contrary to POSIX 2008
> >>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
> >>
> >> Where does it say this?  I read it through in detail but I didn't see
> >> that it required a diagnostic to be emitted in the case that value is
> >> am empty string.  What did I miss?
> > 
> > Oh!  You're right.  Thanks for pointing that out.
> > It's only the source (2nd argument) to symlink that may not
> > be the empty string.
> 
> I also checked POSIX 2008 TC1 (in the middle of ratification process),
> and while it altered the wording, it still mentions only path2:
> 
> On Page: 2058 Line: 65095 Section: symlink()
> In the ERRORS section, change the [ENOENT] error from:
> [ENOENT] A component of path2 does not name an existing file or
> path2 is an empty string.
> to:
> [ENOENT] A component of the path prefix of path2 does not name an
> existing file or path2 is an empty string.
> [ENOENT] or [ENOTDIR]
> The path2 argument contains at least one non-<slash> character and ends
> with one or more trailing <slash> characters. If path2 names an existing
> file, an [ENOENT] error shall not occur.
> Rationale: Austin Group Defect Report(s) applied: 146,428,436.
> See http://austingroupbugs.net/view.php?id=146
> See http://austingroupbugs.net/view.php?id=428
> See http://austingroupbugs.net/view.php?id=436
> 
> What do others on the Austin Group think about an empty string for path1
> in symlink()?

The 2nd paragraph of the description clearly states:

    The string pointed to by path1 shall be treated only as a
    character string and shall not be validated as a pathname.

An implementation which gives an ENOENT error for an empty path1 string
is treating the string as a pathname and therefore does not conform.

> Current Linux rejects the symlink() call with ENOENT;
> FreeBSD 8.2 allows it but refuses to resolve the symlink ("ln -s '' a &&
> ls a/" reports ENOENT); Solaris 10 allows it and resolves the symlink as
> though it were '.' ("ln -s '' a && ls a/" reports the current directory
> contents).

Presumably if you follow the pathname resolution rules to the letter
you will end up with either the FreeBSD or the Solaris behaviour
being the required one.  Of course, whichever one it is, that may
be an accidental outcome of the way the pathname resolution section
is written rather than an intention to disallow the other behaviour.

-- 
Geoff Clare <g.clare <at> opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

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

From: Joerg Schilling <Joerg.Schilling <at> fokus.fraunhofer.de>
To: <jim <at> meyering.net>, <eblake <at> redhat.com>
Cc: 13447 <at> debbugs.gnu.org, ken.irving <at> alaska.edu, austin-group-l <at> opengroup.org,
	bob <at> proulx.com
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Wed, 16 Jan 2013 12:07:27 +0100

Eric Blake <eblake <at> redhat.com> wrote:

> [adding the Austin Group]
>
> On 01/15/2013 02:58 AM, Jim Meyering wrote:
>
> >>> That Solaris behavior is contrary to POSIX 2008
> >>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
> >>
> >> Where does it say this?  I read it through in detail but I didn't see
> >> that it required a diagnostic to be emitted in the case that value is
> >> am empty string.  What did I miss?
> > 
> > Oh!  You're right.  Thanks for pointing that out.
> > It's only the source (2nd argument) to symlink that may not
> > be the empty string.
>
> I also checked POSIX 2008 TC1 (in the middle of ratification process),
> and while it altered the wording, it still mentions only path2:
>
> On Page: 2058 Line: 65095 Section: symlink()
> In the ERRORS section, change the [ENOENT] error from:
> [ENOENT] A component of path2 does not name an existing file or
> path2 is an empty string.
> to:
> [ENOENT] A component of the path prefix of path2 does not name an
> existing file or path2 is an empty string.
> [ENOENT] or [ENOTDIR]
> The path2 argument contains at least one non-<slash> character and ends
> with one or more trailing <slash> characters. If path2 names an existing
> file, an [ENOENT] error shall not occur.
> Rationale: Austin Group Defect Report(s) applied: 146,428,436.
> See http://austingroupbugs.net/view.php?id=146
> See http://austingroupbugs.net/view.php?id=428
> See http://austingroupbugs.net/view.php?id=436
>
> What do others on the Austin Group think about an empty string for path1
> in symlink()?  Current Linux rejects the symlink() call with ENOENT;
> FreeBSD 8.2 allows it but refuses to resolve the symlink ("ln -s '' a &&
> ls a/" reports ENOENT); Solaris 10 allows it and resolves the symlink as
> though it were '.' ("ln -s '' a && ls a/" reports the current directory
> contents).

I believe that symlink("", "foo") should be valid according to
http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html

On the other side, Solaris (correctly) returns ENOENT for open("", O_RDONLY);
so the question is how symlink processing should be done in the kernel. 

If the symlink target is to be treated as a list of path name components, 
I would expect ENOENT with an attempt to open() or stat() "a/".

If the symlink target is treated as a string that is concatenated to the 
previous path, Solaris could be seen as correct.

Solaris replaces an empty symlink target ("") by "." before replacing the 
current path name component in the path currently being processed by the 
symlink target string before continuing with the path processing on the 
resulting path.

Jörg

-- 
 EMail:joerg <at> schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js <at> cs.tu-berlin.de                (uni)  
       joerg.schilling <at> fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Joerg Schilling <Joerg.Schilling <at> fokus.fraunhofer.de>
Cc: jim <at> meyering.net, austin-group-l <at> opengroup.org, 13447 <at> debbugs.gnu.org,
	ken.irving <at> alaska.edu, bob <at> proulx.com, eblake <at> redhat.com
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Wed, 16 Jan 2013 09:58:20 -0800

On 01/16/13 03:07, Joerg Schilling wrote:
> If the symlink target is to be treated as a list of path name components, 
> I would expect ENOENT with an attempt to open() or stat() "a/".
> 
> If the symlink target is treated as a string that is concatenated to the 
> previous path, Solaris could be seen as correct.

Except that Solaris also treats the symlink as "." even if there is
no previous path.  For example, on Solaris 11:

$ ln -s '' empty
$ ls -l empty
lrwxrwxrwx   1 eggert   faculty        0 Jan 16 09:56 empty -> 
$ cat empty
cat: input error on empty: Is a directory
$ cat ''
cat: cannot open : No such file or directory

This is an undesirable inconsistency, and it's hard to see how
any user would want this behavior.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 13447 <at> debbugs.gnu.org, Ken Irving <ken.irving <at> alaska.edu>
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Thu, 17 Jan 2013 13:09:20 +0000

[Message part 1 (text/plain, inline)]

On 01/15/2013 02:27 PM, Jim Meyering wrote:
> Pádraig Brady wrote:
> ...
>>> 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.
>
> Yes, I've demonstrated that rather well ;-)

Note to add the error robustly,
we'd have to check that ENOENT wasn't
in fact being generated for the link name.
That would involve stat()s and TOCTOU issues.

This Linux misinterpretation of POSIX has
been present for a long time as can be seen by
searching for sys_symlink in:

  http://repo.or.cz/w/davej-history.git/blame/HEAD:/fs/namei.c

I sent the attached path to the kernel list,
to see can we address it directly there.

thanks,
Pádraig.

[symlink-empty.diff (text/x-patch, attachment)]

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

From: Eric Blake <eblake <at> redhat.com>
Cc: 13447 <at> debbugs.gnu.org, Ken Irving <ken.irving <at> alaska.edu>,
	Austin Group <austin-group-l <at> opengroup.org>,
	Jim Meyering <jim <at> meyering.net>, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13447: ln "" foo gives misleading error message
Date: Thu, 17 Jan 2013 09:08:51 -0700

[Message part 1 (text/plain, inline)]

On 01/15/2013 07:15 AM, Eric Blake wrote:
> [adding the Austin Group]
> 

> 
> What do others on the Austin Group think about an empty string for path1
> in symlink()?  Current Linux rejects the symlink() call with ENOENT;
> FreeBSD 8.2 allows it but refuses to resolve the symlink ("ln -s '' a &&
> ls a/" reports ENOENT); Solaris 10 allows it and resolves the symlink as
> though it were '.' ("ln -s '' a && ls a/" reports the current directory
> contents).

In today's Austin Group meeting, I was tasked to open a new bug that
would state specifically how the empty symlink is resolved; the intent
is to allow both Solaris behavior (current directory) and BSD behavior
(ENOENT).  Meanwhile, everyone was in agreement that the Linux kernel
has a bug for rejecting the creation of an empty symlink, but once that
bug is fixed, then Linux can choose either Solaris or BSD behavior for
how to resolve such a symlink.

It will probably be a bug report similar to this one, which regarded how
to handle a symlink containing just slashes:
http://austingroupbugs.net/view.php?id=541

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #57 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: Thu, 17 Jan 2013 17:44:06 +0100

Pádraig Brady wrote:
> On 01/15/2013 02:27 PM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>> ...
>>>> 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.
>>
>> Yes, I've demonstrated that rather well ;-)
>
> Note to add the error robustly,
> we'd have to check that ENOENT wasn't
> in fact being generated for the link name.
> That would involve stat()s and TOCTOU issues.
>
> This Linux misinterpretation of POSIX has
> been present for a long time as can be seen by
> searching for sys_symlink in:
>
>   http://repo.or.cz/w/davej-history.git/blame/HEAD:/fs/namei.c
>
> I sent the attached path to the kernel list,
> to see can we address it directly there.

Nice follow-up.  Thanks!

Previous Next

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