Paul Eggert <[EMAIL PROTECTED]> wrote:
> CVS coreutils rm failed "make check" due to the following scenario
> in tests/rm/inaccessible:
>
> can't get the working directory initially;
> ...
> chdir ("/foo/bar/abs1");
> ... opendir, readdir, remove all entries here; then: ...
> chdir ("."); // because we couldn't get the working directory initially
> rmdir ("/foo/bar/abs1");
> ...
>
> Solaris doesn't let you remove the working directory, so rmdir fails.
>
> The fix is to replace that chdir (".") with a chdir ("/"), so I
> installed the following patch. However, I'd like other pairs of eyes
> to verify this one, as I'm a bit leery of executing chdir ("/") in a
> program that is removing everything in sight!
>
> I thought of using chdir ("..") instead but worried it might fail too,
> e.g., if two rm processes are running simultaneously -- perhaps I was
> worrying too much?
Thanks for finding/fixing that!
I think that using "/" is the way to go. Another reason not to use
".." is that the initial directory in your example may have been
/foo/bar, so the chdir ("..") would fail for the same reason that
the initial save_cwd failed. However, a devil's advocate might
argue that rm *should* fail, and that using chdir "/" to avoid the
failure is wrong or at least surprising on such a system.
For the interested reader, bear in mind that this particular failure
arises only in the contrived case in which `rm -r' is run from an
inaccessible (i.e. the user can no longer chdir into it) working
directory to remove more than one absolute-named hierarchy.
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
