Date: Thu, 19 Sep 2002 14:13:51 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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).