Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <3EBD44FE.9030801@ece.gatech.edu>
Date: Sat, 10 May 2003 14:29:18 -0400
From: Charles Wilson <cwilson@ece.gatech.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: cygipc (and PostgreSQL) XP problem resolved!
References: <3EBB22F5.4000801@ece.gatech.edu> <1052541657.1675.5.camel@localhost> <3EBC8ED0.4040906@ece.gatech.edu> <20030510072239.GA19367@cygbert.vinschen.de> <1052554219.1824.14.camel@localhost> <20030510082949.GD19367@cygbert.vinschen.de> <3EBD3179.6070004@ece.gatech.edu> <20030510171629.GB11448@redhat.com> <3EBD3896.8000202@ece.gatech.edu> <20030510174455.GB12325@redhat.com> <20030510175116.GS19367@cygbert.vinschen.de>
In-Reply-To: <20030510175116.GS19367@cygbert.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Corinna Vinschen wrote:

> On Sat, May 10, 2003 at 01:44:55PM -0400, Christopher Faylor wrote:
> 
>>I assume that, in most cases, the high order byte is probably
>>zero but I don't know for sure.
> 
> 
> It's not 0.  I recall examining the inode number on NTFS years ago
> and the high word used different non-0 values, strangly not very
> much of them.  It looked like a pattern which I just didn't understand.
> That was on NT4, AFAIR.

Actually, that sounds promising.  Mebbe I'll whip up a simple mingw prog 
to scan an entire drive and dump out inodes:

Hi32 \t Lo32 \n

And snarf that into MatLab and look for patterns.  Unless somebody 
already has code to do that?

OTOH, maybe ftok() should just use hash_path_name() and not st.ino. 
That returns a 32bit value...

--Chuck

P.S.
emacs and xemacs sourcecode says:

    /* Might as well use file index to fake inode values, but this
       is not guaranteed to be unique unless we keep a handle open
       all the time (even then there are situations where it is
       not unique).  Reputedly, there are at most 48 bits of info
       (on NTFS, presumably less on FAT). */
    fake_inode = info.nFileIndexLow ^ info.nFileIndexHigh;

P.P.S
The linux 'man ftok' page says:

        The generated key_t value is obtained  stat-ing  the  disk
        file  corresponding to pathname in order to get its i-node
        number and the minor device number of  the  filesystem  on
        which  the  disk file resides, then by combining the 8 bit
        proj value along with the lower 16 bits of the i-node num­
        ber,  along  with  the  8 bits of the minor device number.
        The algorithm does not guarantee a unique key  value.   In
        fact

        ·      Two  different  names linking to the same file pro­
               duce same key values.

        ·      Using the lower 16 bits of the i-node number, gives
               some  chance  (also usually small) to have same key
               values  for  file  names  referring  to   different
               i-nodes.

        ·      Not  discriminating  among  major  device  numbers,
               gives some chance of collision (also usually small)
               for systems with multiple disk controllers.

I wonder.  If linux isn't worried too much about the problem, should we? 
(That is, back to Corinna's question: why change from 32bits to 64?)


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/