Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3D8F7CCD.512611C8@phekda.freeserve.co.uk>
Date: Mon, 23 Sep 2002 21:42:53 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: Andrew Cottrell <acottrel AT ihug DOT com DOT au>
CC: djgpp-workers AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: Two rm.exe issues on XP
References: <10208312054 DOT AA20561 AT clio DOT rice DOT edu> <003501c2517e$2e4fdc30$0100a8c0 AT p4>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Andrew Cottrell wrote:
[snip]
> I didn't try this yesterday, but I did once I read the email and the rm.exe
> from simtel's fil41b.zip works fine with the example. I now expect that the
> problem is in a 2.04 CVS LIBC change or series of changes.
[snip]

I guess we already know that 2.03 and CVS are just as broken as each other,
but I got error messages about the inodes yesterday, when using rm.exe under
Windows NT 4 (without LFN TSR) under VMware 3.2.

So here's a proposed fix:

* We add a hack (#ifdef/#endif) to Fileutils 4.1, to not check for the inode
number changing, for DJGPP 2.03. From your earlier posts, Andrew, it sounds
like this may not work.

* We fix DJGPP CVS to calculate the inode the same way, so that the check
doesn't fail.

I didn't have any time to look at this issue properly at the weekend.
Hopefully I will have some time this weekend.

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]