键值 = 文件标示符 + 项目ID
当用到进程间的通信时， 必须要注意到的是键值是怎么产生的，我们知道任何一个文件时通过文件名来访问的， 而内核在对应的给其一个值，也就是文件标示符。
系统建立IPC通讯（如消息队列、共享内存时）必须指定一个ID值 。通常情况下，该id值通过ftok函数得到 。 ftok原型如下：
key_t ftok( char * fname, int id )
此时这个 id也就是项目 ID，最后将两者结合生成了键值！这里所谓的文件标示符其实下面提到的 内核的物理编号，也就是索引节点 inode。
参数说明： fname就时您指定的文档名, id是子序号。
关于linux中的软链接和硬链接
Linux中有两种类型的链接：(这个与 Windows上 FAT32 或 NTFS是不一样的！)
硬链接是利用Linux中为每个文件分配的物理编号——inode建立链接。因此，硬链接不能跨越文件系统。（用ls –i命令可以查看目录下文件的inode编程）。
软链接（符号链接）是利用文件的路径名建立链接。通常建立软链接使用绝对路径而不是相对路径，以最大限度增加可移植性。
i节点包含了所有与文件有关的信息：文件类型、文件存取许可权位、文件长度和指向该文件所占用的数据块的指针等，stat结构中的大多数信息都取自 i节点。只有两数据项存放在目录项中：文件名和i节点编号数。
因为目录项中的i节点编号数指向同一文件系统中的 i节点，所以不能使一个目录项指向另一个文件系统的i节点。硬链接不能跨文件系统，软链接可以。即每个文件系统有自己的i节点编号。
在一般的UNIX实现中，是将文档的索引节点号取出，前面加上子序号得到key_t的返回值。 如指定文档的索引节点号为65538，换算成16进制为0x010002，而您指定的ID值为38，换算成16进制 为 0x26，则最后的key_t返回值为0x26010002。
查询文档索引节点号的方法是： ls -i
当删除重建文档后，索引节点号由操作系统根据当时文档系统的使用情况分配，因此和原来不同，所以得到的索引节点号也不同。
假如要确保key_t值不变，要目确保ftok的文档不被删除 ，要么不用ftok，指定一个固定的key_t值。
另外说一句：在aix等操作系统上，有多个文档系统，会出现分布在不同的文档系统上的两个文档具备相同的索引节点号，此时用ftok对这两个文档进行操作，只要id参数不变，得到的key_t值相同，造成创建消息队列失败。但是这种情况相当少见罢了。
因为在开发中涉及多种系统平台，在系统移植时发现ftok()函数在不同平台下存在一定的差异性。当然，根本原因不在于ftok()本身，而应该是操作系统对于文件系统管理的差异性。
测试代码如下：
[code]#include ;
#include ;
main()
{
sprintf( "key=%0x/n", ftok( "aaa.txt", 1000 ) );
}
[/code]
测试涉及的操作系统：RedHat AS3U3、Sco OpenServer 5.0.6、UnixWare 7.1.1、Solaris 9 x86 u7。
在RH AS3环境下，对aaa.txt进行修改后程序的输出值都有变化，说明该文件在修改后存储位置发生了变化。
在Sco OpenServer 5.0.6、UnixWare 7.1.1、Solaris 9 x86 u7下执行相同的程序，无论对aaa.txt的文件内容做何种修改都对程序的输出无影响。
因此，如果在linux下通过ftok()产生ipc键值、且ftok()与配置文件相关，则在更改了配置文件后必须将应用重起。否则将导致不可预料的后果！
看以下程序：