Messages in this thread Patch in this message | | | Date | Fri, 12 Feb 1999 13:09:31 +0100 | From | Ralf Corsepius <> | Subject | Re: rmdir of a busy directory |
| |
Alexander Viro wrote:
> On Fri, 12 Feb 1999, Ralf Corsepius wrote: > > > This might also be consequence of the same problem: > > > > mkdir <somedir> > > cd <somedir> > > rmdir . > > > > Under all OSes I tried, the rmdir . command above returns an error. On linux > > > 2.1.124 (the version I first noticed to be affected) this silently succeeds. > > You never tried 4.4BSD, right? >
True.
I checked against SunOS, Solaris (2.4-2.6), linux-2.0.3X, Irix-<something> and hpux-<something> when 2.1.124 was new. AFAIK from other persons' reports, Cygwin32/NT, FreeBSD and Next also report error messages.
> > BTW, this behaviour breaks building egcs/gcc/fixincludes for cross-compilers > > under linux, because fixincludes (egcs-1.1b and egcs-1.1.1) contain a fragment > > which rely on "rmdir ." failing. > > Then egcs/gcc is broken. Period. POSIX doesn't mandate failure on > such operation.
May-be, I don't know what POSIX says about "rmdir" or rmdir().
However, the new behaviour of "rmdir" seems arkward to me: After excuting the command sequence above you can still "ls" in <somedir>, but "ls .." doesn't show <somedir>, bash's command prompt also reports to be still in <somedir>.
I reported this to egcs-bugs in Oct 98 but didn't get any response (I've just checked the egcs-bugs archive, but my mail seems to be corrupted in the archive).
> All *BSD do the same as Linux. And this behaviour is > consistent with unlink().
Are you sure? I don't have access to *BSD systems, therefore I don't have an opportunity to check it myself. Until now I've read bug reports related to the egcs/gcc/fixincludes problem for linux > 2.1.124 only - Not having read about FreeBSD makes me wonder.
May-be it's not a "rmdir()" problem but a "rmdir"-problem (fileutils-3.16).
> Notice that it may be even fs-dependent.
I know - I was using ext2, if that matters.
> Out of curiosity - how does this fragment look like?
Cf. the patch below (The patch I use to work around this problem) - egcs-1.1.1 also is affected.
> Final word belongs Linus, indeed, but IMO reverting to -EBUSY on > rmdir() is *wrong*.
I am not a linux-kernel hacker nor an egcs-developer, nor am I knowledgeable enough to judge, so won't I argue for this.
This time "Linux has changed its (probably undocumented) behaviour, which has always worked in the past :-" (no flames, please - I want this problem to be fixed, either in the kernel or in egcs/gcc/fixincludes)
Ralf.
-- Ralf Corsepius Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW) Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999 http://www.faw.uni-ulm.de
--- egcs-1.1b.orig/gcc/fixincludes Thu Sep 3 01:39:06 1998 +++ egcs-1.1b/gcc/fixincludes Thu Oct 15 11:30:43 1998 @@ -3123,7 +3123,7 @@ cd $LIB files=`find . -type d -print | sort -r` for file in $files; do - rmdir $LIB/$file > /dev/null 2>&1 + test x"$file" = x"." || rmdir $LIB/$file > /dev/null 2>&1 done | |