ftok()函数在不同平台下实现的兼容性

sunlan

因为在开发中涉及多种系统平台，在系统移植时发现ftok()函数在不同平台下存在一定的差异性。当然，根本原因不在于ftok()本身，而应该是操作系统对于文件系统管理的差异性。

测试代码如下：

1. #include <stdio.h>;
   
2. #include <sys/ipc.h>;
   
3. 
   
4. main()
   
5. {
   
6.     sprintf( "key=%0x\n", ftok( "aaa.txt", 1000 ) );
   
7. }
   

复制代码

测试涉及的操作系统：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()与配置文件相关，则在更改了配置文件后必须将应用重起。否则将导致不可预料的后果！

flw

I 服了 U！
IPC 本来就是在同一台机器上通讯用的嘛！

flw

刚才试了一下，
RH9 下修改了 f 确实会影响 k，
再看 RH9 下对 ftok 的 man：

1. FTOK(3)                    Linux Programmer's Manual                   FTOK(3)
   
2. 
   
3. NAME
   
4.        ftok  -  convert  a pathname and a project identifier to a System V IPC
   
5.        key
   
6. 
   
7. SYNOPSIS
   
8.        # include <sys/types.h>;
   
9.        # include <sys/ipc.h>;
   
10. 
    
11.        key_t ftok(const char *pathname, int proj_id);
    
12. 
    
13. DESCRIPTION
    
14.        The ftok function uses the identity of the  file  named  by  the  given
    
15.        pathname  (which  must  refer  to an existing, accessible file) and the
    
16.        least significant 8 bits of proj_id (which must be nonzero) to generate
    
17.        a  key_t  type  System  V  IPC  key,  suitable  for use with msgget(2),
    
18.        semget(2), or shmget(2).
    
19. 
    
20.        The resulting value is the same for all pathnames that  name  the  same
    
21.        file, when the same value of proj_id is used. The value returned should
    
22.        be different when the (simultaneously existing) files  or  the  project
    
23.        IDs differ.
    
24. 
    
25. RETURN VALUE
    
26.        On  success  the  generated  key_t  value is returned. On failure -1 is
    
27.        returned, with errno indicating the error as  for  the  stat(2)  system
    
28.        call.
    
29. 
    
30. CONFORMING TO
    
31.        XPG4
    
32. 
    
33. NOTES
    
34.        Under libc4 and libc5 (and under SunOS 4.x) the prototype was
    
35.               key_t ftok(char *pathname, char proj_id);
    
36.        Today  proj_id is an int, but still only 8 bits are used. Typical usage
    
37.        has an ASCII character proj_id, that is why the behaviour is said to be
    
38.        undefined when proj_id is zero.
    
39. 
    
40.        Of course no guarantee can be given that the resulting key_t is unique.
    
41.        Typically, a best effort attempt combines the given proj_id  byte,  the
    
42.        lower  16 bits of the i-node number, and the lower 8 bits of the device
    
43.        number into a 32-bit result.  Collisions may easily happen, for example
    
44.        between files on /dev/hda1 and files on /dev/sda1.
    
45. 
    
46. SEE ALSO
    
47.        ipc(5), msgget(2), semget(2), shmget(2), stat(2)
    
48. 
    
49. Linux 2.4                         2001-11-28                           FTOK(3)
    

复制代码

按照我对 “ The resulting value is the same for all pathnames that  name  the  same
       file, ” 的理解，似乎不应该这样，
是不是可以认定是 RH9 的一个 BUG？？

albcamus

真的会有变化哦。试了一下，不过变来变去都是2个值中的一个，我的机器是17460896和17460895

albcamus

平时都是这么用的
key_t ftok(getenv("CWD",,1);
这样应该没问题了吧？

FH

一般来说，ftok对应文件的inode，因此，无论多少连接，指向的都是同一个inode。我觉得这句话应该是这样理解的。

sunlan

原帖由 "flw" 发表：
按照我对 “ The resulting value is the same for all pathnames that  name  the  same
       file, ” 的理解，似乎不应该这样，
是不是可以认定是 RH9 的一个 BUG？？

我也是这样认为的！我还没有在别的linux平台下试验过。有机会的话我都会试以下的。

应该来说如果文件的inode未变，ftok()的值也不应该变。除非是在保存原文件的时候实际做了删除->;创建的操作！

sunlan

[quote]原帖由 "albcamus"]真的会有变化哦。试了一下，不过变来变去都是2个值中的一个，我的机器是17460896和17460895[/quote 发表：



还有一种情况未试：新创建一个文件、然后再对aaa.txt做修改，看输出值是否变化。如果变化的话说明保存文件时确实会改动文件的位置！

FH

我觉得改变位置与vi相关吧？

sunlan

[quote]原帖由 "FH"]我觉得改变位置与vi相关吧？[/quote 发表：


如果文件位置确实改变，那的确是由于vi引起的，但其结果倒过来影响到了ftok()的输出。所以我在前头说如果更改了配置文件，而这个配置文件又与ftok()相关的话，那就需要将应用重起。否则将因为不同进程中获得的ipckey不一致而导致程序出错。