Newsgroups: comp.unix.programmer, comp.os.linux.development.system
From: André Gillibert <MetaEntropy.removeT...@gmail.com>
Date: Sat, 17 Dec 2011 11:57:33 +0100
Local: Sat, Dec 17 2011 5:57 am
Subject: Re: ftok() on Linux generated different keys for the same inode and the same file name
Alex Vinokur <alex.vino...@gmail.com> wrote:Download GLIBC source code at
> On Dec 15, 8:16 pm, Huibert Bol <huibert....@quicknet.nl> wrote:
> > Alex Vinokur wrote:
> > > It seems that ftok() on Linux generated different keys for the same
> > > inode and the same file name.
> > > Linux 2.6.18-238.12.1.el5 #1 SMP Sat May 7 20:18:50 EDT 2011 x86_64
> > > AccessTime = 20111020-153001 Inode = 6914144 ShmKeyDec =
> > After a reboot, right? From the source:
> > key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16)
> > The parts that differ are set to the device number, perhaps your disks
> > --
> I am not sure that it was after reboot: difference between asscess
> AccessTime = 20111020-153001 Inode = 6914144 ShmKeyDec =
> Where can I see ftok()-source for Linux?
Or, assuming you are using RHEL, CentOS or Scientific Linux 5, you can
CentOS glibc-2.5-65.src.rpm source code:
if (__xstat64 (_STAT_VER, pathname, &st) < 0)
key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16)
}inode is unreliable on some file systems that have not been designed
for UNIX systems (e.g. remote FAT file system shared through SMB), but
that's not your problem, as the inode is kept consistent and
inode&0xFFFF = 0x8060 is unchanged. Your proj_id is unchanged too
(0x41), but the device node is changed. 0x0B -> 0x0C.
If the device is physically, or logically, unplugged and replugged, the
This may happen with some unreliable USB mass storage device, or
Warning: 16 bits is not enough to store the inode on any file system
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.