Mail Archives: cygwin/2003/05/10/14:31:30
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/
- Raw text -