Date: Mon, 13 Aug 2001 21:55:29 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: sandmann AT clio DOT rice DOT edu
Message-Id: <3395-Mon13Aug2001215529+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com, acottrel AT ihug DOT com DOT au
In-reply-to: <10108131609.AA13344@clio.rice.edu> (sandmann@clio.rice.edu)
Subject: Re: Link function query
References:  <10108131609 DOT AA13344 AT clio DOT rice DOT edu>
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

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Mon, 13 Aug 2001 11:09:38 -0500 (CDT)
> 
> > Yes.  The only part that is allowed to be not equal on Windows is the
> > st_ino member: Windows doesn't give us enough info to get the full
> > path of the file name by its handle (on plain DOS, even st_ino is
> > identical).
> 
> LFN function 71a6 (info by handle) provides a file number which is
> supposedly unique - should we be trying to use this with fstat?

Maybe, I don't know.

The problem is Windows doesn't guarantee this number to stay put if
you close and reopen the file.  It also runs the risk of incidentally
returning the same number as stat returns for some different file,
which current implementation avoids.  Returning the same inode for two
different files leads to subtle bugs.

For these reasons, I decided at the time not to use this Windows
feature.  But that was a long time ago, so maybe we should revisit
that decision.