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