From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10308171323.AA13190@clio.rice.edu>
Subject:	Re: inode problem in `rm'
To:	djgpp-workers AT delorie DOT com
Date:	Sun, 17 Aug 2003 08:23:51 -0500 (CDT)
Cc:	rich AT phekda DOT freeserve DOT co DOT uk ('Richard Dawe'),
	eliz AT elta DOT co DOT il ('Eli Zaretskii')
In-Reply-To:	<000001c363d3$15b700f0$0101a8c0@acp42g> from "Andrew Cottrell" at Aug 16, 2003 06:47:48 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

> I have removed the inode check in my rm.exe and I now have uncovered anot=
> her
> problem with the LIBC rmdir.c code below in that it failes to remove a
> directory and as such the rm -rf contrib fails. I have tried both 0x3a an=
> d
> 0x713a int21 calls, but they both fail. I am running Win XP Pro with all =
> the
> patches.

This is usually a sign that some process has the default directory 
being that directory.  I have seen cases where the NTVDM still has
it's default directory deep in a tree so I can't even remove the
tree with rmdir /s from the command line.  I can't be sure, but it
seems that sometimes images set default directory and then don't 
restore it. 

Things to try:
 0) Make sure no other windows are open with default directory in tree.
 1) Can you remove the directory from a CMD.EXE prompt?
 2) If that fails, does killing NTVDM.EXE process allow it to work?

- Raw text -