[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.026 / U:7.920 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site