ftok() on Linux generated different keys for the same inode and the same file name

[Alex Vinokur]

Hi,

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
x86_64 x86_64 GNU/Linux

AccessTime = 20111020-153001 Inode = 6914144 ShmKeyDec =
1091272800 ShmKeyHex = 0x410b8060
AccessTime = 20111020-155359 Inode = 6914144 ShmKeyDec =
1091338336 ShmKeyHex = 0x410c8060

Thanks

[Alex Vinokur]

P.S. File wasn't deleted. It is the same file.

Alex

[Huibert Bol]

After a reboot, right? From the source:

key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16)
| ((proj_id & 0xff) << 24));

The parts that differ are set to the device number, perhaps your disks
were detected in a different order.

--
Huibert
"Okay... really not something I needed to see." --Raven

[Alex Vinokur]

I am not sure that it was after reboot: difference between asscess
times is about 4 min.
I don't know.

AccessTime = 20111020-153001 Inode = 6914144 ShmKeyDec =
1091272800 ShmKeyHex = 0x410b8060
AccessTime = 20111020-155359 Inode = 6914144 ShmKeyDec =
1091338336 ShmKeyHex = 0x410c8060

Where can I see ftok()-source for Linux?

Thanks

Alex

[Alex Vinokur]

On Dec 15, 8:16 pm, Huibert Bol <huibert....@quicknet.nl> wrote:

...

>   key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16)
>          | ((proj_id & 0xff) << 24));

...

proj_id - what is it? Second argument of ftok()?

st.st_ino - inode of the file ?

Thanks

[Huibert Bol]

Alex Vinokur wrote:

> Where can I see ftok()-source for Linux?

I can never remember, I just typed "gdb /lib64/libc-*" and then "list
ftok".

[André Gillibert]

Download GLIBC source code at
<ftp://ftp.gnu.org/gnu/glibc/>.

Or, assuming you are using RHEL, CentOS or Scientific Linux 5, you can
get the source code, with additionnal patches at:
<http://vault.centos.org/5.7/os/SRPMS/glibc-2.5-65.src.rpm>

CentOS glibc-2.5-65.src.rpm source code:
/* sysvipc/ftok.c */
key_t
ftok (pathname, proj_id)
const char *pathname;
int proj_id;
{
struct stat64 st;
key_t key;

if (__xstat64 (_STAT_VER, pathname, &st) < 0)
return (key_t) -1;

key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16)
| ((proj_id & 0xff) << 24));

return key;
}

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
device identifier may be changed (or, the test has been done on
different machines, with NFS shares, but you didn't gave us enough
info to know).
Look at the kernel messages with dmesg, to see if the device
connection gets lost at some point, and revived later.

This may happen with some unreliable USB mass storage device, or
theoritically, this may happen with some SATA drive, although, in my
experience I've only seen SATA drives loose connexion, not regain it.

Warning: 16 bits is not enough to store the inode on any file system
having more than 65536 files & directories. This function may return
the same value for two different files.

--
André Gillibert

[André Gillibert]

Alex Vinokur <alex.v...@gmail.com> wrote:
> On Dec 15, 8:16 pm, Huibert Bol <huibert....@quicknet.nl> wrote:
> ...
> >   key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16)
> >          | ((proj_id & 0xff) << 24));
> ...
>
> proj_id - what is it? Second argument of ftok()?
>

Yes.

> st.st_ino - inode of the file ?
>

Yes.

--
André Gillibert

[Alex Vinokur]

Thank you.

I tried to get ftok's code via gdb.
Failed.


Linux illin793 2.6.18-238.12.1.el5 #1 SMP Sat May 7 20:18:50 EDT 2011
x86_64 x86_64 x86_64 GNU/Linux


> ls -l /lib64/libc-2.5.so
-rwxr-xr-x 1 root root 1722304 Dec 14 2010 /lib64/libc-2.5.so

> nm /lib64/libc-2.5.so | grep ftok
00000030bc0d52b0 T ftok

> gdb /lib64/libc-2.5.so
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/
gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /lib64/libc-2.5.so...(no debugging symbols
found)...done.
(gdb) list ftok
No symbol table is loaded. Use the "file" command.Undefined command:
"ftok". Try "help".

[Alex Vinokur]

On Dec 17, 12:57 pm, André Gillibert
<MetaEntropy.removeT...@gmail.com> wrote:
...

> If the device is physically, or logically, unplugged and replugged, the
> device identifier may be changed (or, the test has been done on
> different machines, with NFS shares, but you didn't gave us enough
> info to know).
> Look at the kernel messages with dmesg, to see if the device
> connection gets lost at some point, and revived later.
>
> This may happen with some unreliable USB mass storage device, or
> theoritically, this may happen with some SATA drive, although, in my
> experience I've only seen SATA drives loose connexion, not regain it.
>
> Warning: 16 bits is not enough to store the inode on any file system
> having more than 65536 files & directories. This function may return
> the same value for two different files.

...

Thank you.

Does it mean that st_dev may be changed while running without reboot?

Thanks.

Alex

[Huibert Bol]

Alex Vinokur wrote:

>> gdb /lib64/libc-2.5.so

> Reading symbols from /lib64/libc-2.5.so...(no debugging symbols
> found)...done.

You're missing the debug package. It will named glibc-debuginfo or
something similar.

[Alex Vinokur]

Thanks

Alex

[André Gillibert]

This shouldn't happen randomly, but this may happen if the device is
unmounted & remounted.

For example, unmounting a NFS file system, and remounting it, gives a
different dev_t.

Since you didn't specify details (file system, device type, whether
devices are auto-mounted, kernel and udev logs), I cannot know what
exactly happens.

--
André Gillibert