Off hand I don't see anything that relies on the EINVAL error from
diskfs_lookup to distinguish this case. Hence no harm in making it ENOENT
there. The rationale for it returning EINVAL is that "" (like anything
with infix slashes) is an inappropriate argument for "file name within
directory" arguments to RPCs. That seems sensible to me as well. So,
conversely, clients should not be sending such RPCs and libc is what needs
to change. This is consistent with the existing ENOENT on "" check in
hurd_file_name_lookup, which I think just needs to be repeated in
hurd_{file,directory}_name_split. Try this and if it's good I'll check it in.
--- hurdlookup.c.~1.52.~ 2003-02-25 16:21:43.000000000 -0800
+++ hurdlookup.c 2004-04-30 13:25:07.000000000 -0700
@@ -141,6 +142,8 @@ __hurd_file_name_split (error_t (*use_in
dirname, 0, 0, dir);
}
}
+ else if (file_name[0] == '\0')
+ return ENOENT;
else
{
/* "foobar" => cwdir + "foobar". */
@@ -216,6 +219,8 @@ __hurd_directory_name_split (error_t (*u
dirname, 0, 0, dir);
}
}
+ else if (file_name[0] == '\0')
+ return ENOENT;
else
{
/* "foobar" => cwdir + "foobar". */
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
