根據pathname指定的文件（或目錄）名稱，以及proj_id參數指定的數字，ftok函數為IPC對象生成一個唯一性的鍵值。在實際應 用中，很容易產生的一個理解是，在proj_id相同的情況下，只要文件（或目錄）名稱不變，就可以確保ftok返回始終一致的鍵值。然而，這個理解並非 完全正確，有可能給應用開發埋下很隱晦的陷阱。因為ftok的實現存在這樣的風險，即在訪問同一共享內存的多個進程先后調用ftok函數的時間段中，如果 pathname指定的文件（或目錄）被刪除且重新創建，則文件系統會賦予這個同名文件（或目錄）新的i節點信息，於是這些進程所調用的ftok雖然都能 正常返回，但得到的鍵值卻並不能保證相同。由此可能造成的后果是，原本這些進程意圖訪問一個相同的共享內存對象，然而由於它們各自得到的鍵值不同，實際上 進程指向的共享內存不再一致；如果這些共享內存都得到創建，則在整個應用運行的過程中表面上不會報出任何錯誤，然而通過一個共享內存對象進行數據傳輸的目 的將無法實現。
AIX、Solaris、HP-UX均明確指出，key文件被刪除並重建后，不保證通過ftok得到的鍵值不變，比如AIX上ftok的man幫助信息即聲明：
Attention: If the Path parameter of the ftok subroutine names a file that has been removed while keys still refer to it, the ftok subroutine returns an error. If that file is then re-created, the ftok subroutine will probably return a key different from the original one.
Linux沒有提供類似的明確聲明，但我們可以通過下面的簡單例程test01.c，得到相同的印證：
將上述例程在Red Hat Enterprise Linux AS release 4平台上編程成可執行程序test01，並且通過touch命令在 /tmp目錄下創建一個新文件mykeyfile，然后為該文件生成鍵值：
然后，將/tmp/mykeyfile刪除，並且通過vi命令重新創建該文件，再次生成鍵值：
們可以看到，雖然文件名稱都是 /tmp/mykeyfile，並未改變，但由於中間發生了文件刪除並重新創建的操作，前后兩次所得到的鍵值已經不再相同。
避免此類問題最根本的方法，就是采取措施保證pathname所指定的文件（或目錄）在共享內存的使用期間不被刪除，不要使用有可能被刪除的文件；或者干脆直接指定鍵值，而不借助ftok來獲取鍵值。
我在CENTOS5.2下實測結果：如果用同樣的方式創建mykeyfile，得到的鍵值不變。
如果創建方式不同則鍵值不同。