[lkml]   [1999]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: 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?


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

> > 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 Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 FAX: +49/731/501-999

--- 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

 \ /
  Last update: 2005-03-22 13:50    [W:0.069 / U:0.332 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site