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]

NTFS inode numbers (was Re: cygipc (and PostgreSQL) XP problem resolved!)

On Sat, May 10, 2003 at 02:29:18PM -0400, Charles Wilson wrote:
> 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?

I've just written a small Ruby script to check the inode numbers on NTFS
I've tested > 110000 files and it turned out that for some reason only
the upper word of the FileIndexHigh value is used.  I've got only 546
different values between 0x00010000 and 0xffff0000.  The low word was
0x0000 in all cases.  So the inode value as a whole is apparently a 48 bit

FileIndexLow is also interesting.  I got 103812 different values but none
of these values was bigger than 0x0003ffff.  So it *looks* as if the upper
14 bits aren't used in FileIndexLow. 

This would result in FileIndex being a 34 bit value.

Naaah, that sounds too weird.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

Unsubscribe info:
Problem reports:

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