Message-ID: <004001c263b3$60489320$0100a8c0@p4>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: "Richard Dawe" <rich AT phekda DOT freeserve DOT co DOT uk>
Cc: <djgpp-workers AT delorie DOT com>, "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
References: <10208312054 DOT AA20561 AT clio DOT rice DOT edu> <003501c2517e$2e4fdc30$0100a8c0 AT p4> <3D8F7CCD DOT 512611C8 AT phekda DOT freeserve DOT co DOT uk>
Subject: Re: Two rm.exe issues on XP
Date: Tue, 24 Sep 2002 20:15:27 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Reply-To: djgpp-workers AT delorie DOT com

> > 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.

I tried to #ifdef/#endif out the assert and the check and I seemed to get
into some sort of recursive loop in rm.exe as it never stopped until I
CTRL-C'd it. I may not have #ifdef/#endif the right bit.

> * We fix DJGPP CVS to calculate the inode the same way, so that the check
> doesn't fail.
It looks like lstat() returns the correct inode (same), but I need to spend
some more time debugging remove.c

> I didn't have any time to look at this issue properly at the weekend.
> Hopefully I will have some time this weekend.
That makes two of us.

Andrew