glibc: new patch to fix *_name_split() and callers

[Jérémie Koenig]

Hi again,

While working on a new patch with special cases I realized that
file_name_split() can return an empty name too, namely in the case of
an existing directory with trailing slashes. This is poorly handled by
callers as well. For instance:

  $ ln -T existing_file existing_dir/
  ln: creating hard link `existing_dir/' => `existing_file': Invalid argument
  $ ln -sT existing_file existing_dir/
  ln: creating symbolic link `existing_dir1/': Invalid argument

The attached patch (untested yet) attempts to fix all these cases, by
testing for the empty string whenever a call to a name_split()
function is made. Unlike the previous one it does not change the
interface, but it clarifies the comments in hurd.h.

On Sun, Jun 13, 2010 at 10:04 PM, Roland McGrath <roland@frob.com> wrote:
> Right.  That does make sense for the RPCs themselves.  OTOH for the libc
> calls we do want the other errors instead of EINVAL (which IMHO here is
> nearly as bizarre to a user as EGRATUITOUS would be), and adding special
> cases just feels wrong.

I agree it's not ideal, but I'm not sure we really have a choice since
the sensible errors to return depend on what is being attempted. Also
it turns out it's not so special after all, since everyone needs it
;-)

Maybe adding an argument to the __*_name_split() functions would be
somewhat cleaner? We would need yet another version to maintain the
external interfaces, though. Or maybe just change them and #define the
two-arguments form, if this is possible?

> [we're free to introduce new errors for non-specified situations]
>
> On Linux, the errors are:
>
> mkdir, mknod, link - EEXIST
> unlink - EISDIR

I beleive on Hurd we would want EPERM since it's what POSIX specifies
and what the translators do for non-root directories.

> rmdir - EBUSY
>
> [we should diagnose before RPC]
> Those error codes make sense except possibly for the EBUSY case.

Among the specified error codes, EBUSY seems to be be the one for
which the described circumstances have the closest resemblance to our
particular problem, so I used it anyway.

I'll test the patch tomorrow and post the results,
-- 
Jérémie Koenig <jk@jk.fr.eu.org>
http://jk.fr.eu.org/

0001-Hurd-Fix-split_directory_name-handle-an-empty-NAME-i.patch
Description: Text Data