ftok() 碰撞
我正在使用 ftok() 为 C 应用程序使用的共享内存段生成标识符。我遇到了问题，在一个盒子上我与 root 使用的标识符发生冲突。在这种情况下，我可以通过破解代码来修复它，但我想要一个更强大的解决方案。
应用程序安装到其自己的逻辑卷中，提供给 ftok 的路径是应用程序的二进制文件目录（在该 lv 内）。提供的 ID 从 1 开始，通常有六个左右。
我发现 ftok 会做这样的事情：
(id & 0xff) << 24 | (st.st_dev & 0xff) << 16 | (st.st_ino & 0xffff)
st.st_dev / st.st_ino 的组合应该是非常独特的。但我在许多盒子中看到，st_dev 的最低有效位通常是 0（即 st_dev 数字通常是 256 的倍数）。而且由于二进制目录位于逻辑卷中，因此无法保证 inode 编号与 root 使用的内容不同。
有没有一个好的方法可以解决这个问题 - ftok 的更好替代方案，或者设置机器的方法，使 st_dev 数字对 ftok 更有用？
I am using ftok() to generate identifiers for shared memory segments used by a C application. I am having problems, where on one box I am getting collisions with the identifiers used by root. I can fix it in this instance by hacking the code, but I would like a more robust solution.
The application is installed into its own logical volume, and the path supplied to ftok is the binaries directory for the application (within that lv). The IDs supplied start at 1 and there are usually half a dozen or so.
I've tracked down that ftok will do something like this:
(id & 0xff) << 24 | (st.st_dev & 0xff) << 16 | (st.st_ino & 0xffff)
The combination of st.st_dev / st.st_ino should be very unique. But I've seen across a number of boxes, the least significant bit of st_dev is often 0 (i.e. st_dev numbers are generally multiples of 256). And because the binary directory is in a logical volume, there is no guarantee that the inode number will be different from something root uses.
Is there a good way around this - a better alternative to ftok, or a way of setting up machines such that the st_dev numbers will be of more use to ftok?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可能需要考虑使用 POSIX 共享内存（通过
shm_open） ，它不会受到这种按键冲突的影响You may want to consider using POSIX shared memory (via
shm_open), which doesn't suffer from this sort of key collision您的应用程序应该始终能够处理按键冲突。密钥可能正在被另一个不相关的进程使用。但您可以尝试使用更多相关位来创建您自己的 ftok() 版本。
理论上，任何应用程序只需要一个“主”密钥，指向可以找到其他密钥的“记分板”。在文件系统上公开主密钥可能是一个好主意。崩溃后重新启动总是会出现问题。
Your application should always be able to deal with key collisions. A key could be in use by another unrelated process. But you could try to create your own version of ftok(), using more relevant bits.
In theory any application needs only one "master" key, pointing to a "scoreboard" where the other keys can be found. Publicizing the masterkey on the filesystem might be a good idea. Restart after a crash will always be a problem.