bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: [bug #6047] rm -f "" prints diagnostic message under the Hurd]


From: Ognyan Kulev
Subject: Re: [Fwd: [bug #6047] rm -f "" prints diagnostic message under the Hurd]
Date: Wed, 28 Apr 2004 19:48:53 +0300
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

Marcus Brinkmann wrote:
"" is not a valid filename.  However, POSIX also specifies that
"unlink" should return ENOENT if path is the empty string.  So maybe
that is the real bug, that the Hurd returns EINVAL and not ENOENT in
this case?  Can you look closer into that?

libdiskfs/lookup.c:diskfs_lookup has the following code (where NAME is what we are looking for):

...
if (name[0] == '\0')
  {
    if (ds)
      diskfs_null_dirstat (ds);
    return EINVAL;
  }
else
...

In glibc, the basic routines for turning file names into ports are hurd/hurdlookup.c:__hurd_file_name_lookup and friends (which end up calling __hurd_file_name_lookup). There is a LOOKUP argument (pointer to function), but I couldn't find where it is used by callers. By default, __dir_lookup is assumed (in hurd/lookup-retry.c). And libdiskfs/dir-lookup.c:dir_lookup RPC relies on diskfs_lookup for the components of the file name.

I've heard that "" file name has some special use in the Hurd. So there is possibility that changing EINVAL to ENOENT will have unexpected sequences. Perhaps Roland or Thomas would enlighten us if such change will break something.

Regards,
ogi





reply via email to

[Prev in Thread] Current Thread [Next in Thread]