[Bug 1767097] Re: ftok() returns different result for same (path, id) pair if the inode of the file is changed

[Mattias Säteri]

So I see. I just don't see how this is meant to be useful, since you
can't know how the function will behave. Any file you choose can always
be changed by someone outside of the program's control, so you can never
know if you will get the same result every time or a different one.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1767097

Title:
  ftok() returns different result for same (path, id) pair if the inode
  of the file is changed

Status in glibc package in Ubuntu:
  New

Bug description:
  Release: Ubuntu 16.04.2 LTS

  Package: libc6:
    Installed: 2.23-0ubuntu7

  The ftok man page states that: "The resulting value is the same for
  all pathnames that name the same file, when the same value of proj_id
  is used".

  However, if you call ftok() twice with the same path and id, and the
  file has been deleted and created again in between (and the inode of
  the file has been changed by this operation, which it will if other
  files were created in between), then the result of ftok() will not be
  the same.

  The following program can be used to reproduce the issue:

  #include <sys/types.h>
  #include <sys/ipc.h>
  #include <stdio.h>
  #include <unistd.h>

  int main(int argc, char **argv)
  {
      int id = 121;
      
      if (argc != 2) {
          printf("Usage: ft <file>\n");
          return 1;
      }

      if (access(argv[1], F_OK) < 0) {
          printf("Failed to access file\n");
          return 1;
      }

      printf("ftok %s %d: 0x%x\n", argv[1], id, ftok(argv[1], (char)id));
      return 0;
  }

  
  Compile it into a binary named 'ft', then do the following:

  $ touch foo
  $ ./ft foo
  ftok foo 121: 0x790225bd
  $ rm foo
  $ touch bar
  $ touch foo
  $ ftok foo
  ftok foo 121: 0x790226ea

  The result is not the same although the path and id are the same,
  which is not what should happen according to the man page.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1767097/+subscriptions