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