Date:	Thu, 19 Sep 2002 14:13:51 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	djgpp-workers AT delorie DOT com, acottrel AT ihug DOT com DOT au
Subject:	Re: Two rm.exe issues on XP
In-Reply-To:	<10209182049.AA13258@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1020919140725.867X-100000@is>
MIME-Version:	1.0
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

On Wed, 18 Sep 2002, Charles Sandmann wrote:

> What if we did a truename on the name after a sucessful open, and stored
> that string for the hashing?

That would solve most of the problems (the exception being some 
hypothetical code which uses direct __dpmi_int or int86 calls to open a 
file).

A more important problem is with inherited handles -- we don't have a way 
to get at the file names in that case.  This includes redirected standard 
handles, of course.

Something like what you propose was considered in the past, but rejected 
because it didn't solve the problem fully enough (see above), and would 
add non-trivial overhead in speed and memory footprint.

> Non-unique inodes is breaking things in the fileutils 4.1, which for 
> security reasons now check to see if the inodes for the directories are 
> the same.  If they change with our stat/fstat, then we need to #ifdef 
> sections of code for use under DJGPP.

Perhaps #ifdef (or some other change that makes that code a no-op) is the 
best solution.  What security problems does Fileutils try to solve with 
that code?

> It seems the consistency problem is worse under V2.04 than under V2.03
> (based on Andrew's observations) - but this needs to be verified.

We should verify that, as I don't see why should it become worse (apart of 
some obscure bug I left behind).

- Raw text -