From: "Andrew Cottrell" <AndrewCottrell AT swiftdsl DOT com DOT au>
To: <djgpp-workers AT delorie DOT com>
Cc: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Subject: RE: inode problem in `rm'
Date: Sun, 10 Aug 2003 16:42:42 +1000
Message-ID: <000001c35f0a$9d510470$0101a8c0@acp42g>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <ullu20zix.fsf@elta.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h7A6gwi19161
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

> From time to time, `rm' version 4.1 fails to recursively 
> remove a directory and prints a message like this:
> 
>     h:\usr\archive>rm -rf contrib manifest
>     rm: ERROR: the directory `contrib/grx246/doc' initially 
> had device/inode
>     numbers 7/268435467, but now (after a chdir into it), the 
> numbers for `.'
>     are 7/268435468.  That means that while rm was running, 
> the directory
>     was replaced with either another directory or a link to another
>     directory.
> 
> Curiously, if I then restart the command (after chdir to the 
> original directory), it stops at a different point.  And, if 
> the directory tree was large, some of its subdirectories are 
> reported ``in use by some program'' and cannot be removed by 
> Windows Explorer (or any other program I have; `rm' reports 
> EPERM) until I kill the DOS box in which I ran the original 
> `rm' command.
> 
> This is on Windows XP.  Perhaps another sign of the problem 
> with _truename that was found in `rename' just a few days ago?

Assuming it's the same rm.exe inode bug that I was chasing last year then if
you are using the fileutils from the 2.04 alpha 1 release and the LIBC from
then I would not expect to see this problem. This is exactly what the
original bug was, it occurred more if you cd's into the directory before you
rm'd it.

You may see this with fileutils 4.1 and the 2.03 libc on XP, but I have not
used this combo.

Check out Richard's 2.04 status page
http://www.phekda.freeserve.co.uk/richdawe/djgpp/2.04/status204.html and go
down to "Issues not specific to DJGPP 2.04, but could be fixed in it" and
have a look about 1/2 down the table for the following:-

The fstat function tries to get the SFT entry for a file, so it can get its
cluster number. The cluster number is used as the inode field. If the SFT
entry cannot be obtained, then an inode is invented. Every time fstat is
called for a file without an SFT entry, a new inode is generated. Perhaps
fstat should use the fixed-up filename to generate the inode. See the
following messages from djgpp-workers: (1), (2), (3). Later: Andrew Cottrell
produced a patch for this, which was extended by Richard Dawe. The fstat
patch needs reviewing and testing.

There are hyperlinks in the paragraph.

Please le me know if this still exists if you use the 2.04 alpha 1 fileutils
as it should have been fixed..... 

Thanks,
Andrew