From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10208311553.AA16505@clio.rice.edu>
Subject: Re: Two rm.exe issues on XP
To: acottrel AT ihug DOT com DOT au (Andrew Cottrell)
Date: Sat, 31 Aug 2002 10:53:20 -0500 (CDT)
Cc: rich AT phekda DOT freeserve DOT co DOT uk (Richard Dawe), djgpp-workers AT delorie DOT com
In-Reply-To: <001f01c24f26$b636c730$0100a8c0@p4> from "Andrew Cottrell" at Aug 29, 2002 04:38:08 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

I suspect what's observed below could also be see on Win2000, but I've been
deferring all non-critical email while I was business traveling.  I don't
have the new file utils or source yet, but if time allows I'll try to
take a look.

A few thoughts:

> PROBLEM 1 - RM.EXE SIGABRT
> Assertion failed at remove.c line 727: fs->have_device

This should be easy to find without any traceback with the source; this
is a new thing not in 4.0 (have_device isn't even in the structure).
Given the bugs in getting the device under Win2K - I wouldn't be 
surprised if we don't have to conditionalize this out of the way.

> PROBLEM 2 - RM.EXE Operation not permitted (EPERM)

> DJGPP_204 C:\dj204\gnu\build.gcc\gcc>rm -rf include
> rm: cannot remove directory `include': Operation not permitted (EPERM)
> 
> DJGPP_204 C:\dj204\gnu\build.gcc\gcc>dir include
>  Volume in drive C has no label.
>  Volume Serial Number is 7058-8AB0
> 
>  Directory of C:\dj204\gnu\build.gcc\gcc\include
> 29/08/2002  04:07 PM    <DIR>          .
> 29/08/2002  04:07 PM    <DIR>          ..
>                0 File(s)              0 bytes
>                2 Dir(s)  20,100,411,392 bytes free
> 
> DJGPP_204 C:\dj204\gnu\build.gcc\gcc>attrib include
>            C:\dj204\gnu\build.gcc\gcc\include

Can you create a reproducible case for this?  If any other process on the
system has a default directory set there you will get this error.  Does
the problem persist after a reboot? (might have zombie ntvdm)