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

[Mattias Säteri]

Thanks for your response.

So, if this is the case then the behavior of the function is essentially
this: given a set of inputs it returns a number. Given the same set of
inputs again, it may return the same number or it may return a
completely different number. It is basically undeterministic, since it
is impossible to guarantee that nobody outside of my control will change
the files on the file system. Why would you want it to behave this way
instead of returning the same value every time for the same (path, id)
pair?

-- 
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