This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygipc (and PostgreSQL) XP problem resolved!

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...


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;

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

       ·      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

       ·      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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]