Mail Archives: djgpp-workers/2003/08/11/01:46:32
> From: "Andrew Cottrell" <AndrewCottrell AT swiftdsl DOT com DOT au>
> Date: Sun, 10 Aug 2003 16:42:42 +1000
>
> 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.
I'm not sure what incarnation of the ported Fileutils I'm using, but I
think it's from alpha 1. "ident rm.exe" reports the following:
$Id: stub.asm built 2003-04-25 16:01:12 by djasm $
$Id: DJGPP libc built Apr 25 2003 16:04:32 by gcc 3.2.2 $
If there's a better version, please tell me where to get it.
> 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.
Sorry, I don't see how fstat could be relevant here: we are talking
about directories, and fstat cannot be possibly called on directories,
since we cannot `open' a directory to get a file descriptor.
- Raw text -