Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3EBD44FE.9030801@ece.gatech.edu>
Date: Sat, 10 May 2003 14:29:18 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygipc (and PostgreSQL) XP problem resolved!
References: <3EBB22F5 DOT 4000801 AT ece DOT gatech DOT edu> <1052541657 DOT 1675 DOT 5 DOT camel AT localhost> <3EBC8ED0 DOT 4040906 AT ece DOT gatech DOT edu> <20030510072239 DOT GA19367 AT cygbert DOT vinschen DOT de> <1052554219 DOT 1824 DOT 14 DOT camel AT localhost> <20030510082949 DOT GD19367 AT cygbert DOT vinschen DOT de> <3EBD3179 DOT 6070004 AT ece DOT gatech DOT edu> <20030510171629 DOT GB11448 AT redhat DOT com> <3EBD3896 DOT 8000202 AT ece DOT gatech DOT edu> <20030510174455 DOT GB12325 AT redhat DOT com> <20030510175116 DOT GS19367 AT cygbert DOT vinschen DOT 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/