cygipc (and PostgreSQL) XP problem resolved!

[Charles Wilson]

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/