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

- Raw text -