"" 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
_______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
