From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10209182049.AA13258@clio.rice.edu>
Subject: Re: Two rm.exe issues on XP
To: eliz AT is DOT elta DOT co DOT il
Date: Wed, 18 Sep 2002 15:49:53 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com, acottrel AT ihug DOT com DOT au
In-Reply-To: <2110-Wed18Sep2002233140+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 18, 2002 11:31:41 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> The fact that ftest.exe and ./ftest.exe produce different inodes is a
> known limitation of fstat on Windows.  I simply know of no way to get
> at the starting cluster of the file on Windows (there's a special
> function of Int 21h to get it on Windows, but that function doesn't
> work on any version of Windows).

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

> Having different inodes for the same file is bad, but not as bad as
> having the same inode for two different files ;-)

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.

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.