0

(Debian 10.5, kernel 4.19.132-1 )

My understanding is that inodes are unique on a given filesystem, and indeed if we look at man inode we get the following assertion:

Each file in a filesystem has a unique inode number.

But I do not appear to be seeing this in practice.

I have a /tmp filesystem defined as follows in fstab:

/dev/mapper/foo-lv_tmp /tmp            xfs     nodev           0       0

But if I experiment with mktemp I get the same inode:

$ mktemp
/tmp/tmp.BovySvY5Fw
$ echo 'foo'> /tmp/tmp.BovySvY5Fw
$ ls -i /tmp/tmp.BovySvY5Fw
135 /tmp/tmp.BovySvY5Fw
$ rm /tmp/tmp.BovySvY5Fw
$ mktemp
/tmp/tmp.UzUQZROBoo
$ echo 'foo'> /tmp/tmp.UzUQZROBoo
$ ls -i /tmp/tmp.UzUQZROBoo
135 /tmp/tmp.UzUQZROBoo
$ rm /tmp/tmp.UzUQZROBoo

I also see the same behaviour outside of /tmp e.g. my home dir:

foo@bar:~$ echo 'a' > foo
foo@bar:~$ ls -i foo
67135721 foo
foo@bar:~$ rm foo 
foo@bar:~$ echo 'a' > foo
foo@bar:~$ ls -i foo
67135721 foo
foo@bar:~$ rm foo
Little Code
  • 199
  • 1
  • 1
  • 9
  • 1
    Your examples don't contradict anything. Once you `rm` a file, it is no longer in the filesystem. So that inode number can be used when you create a new file. – Mat Sep 02 '20 at 11:39
  • @Mat Thanks. So in terms of a scenario where I am writing a script to incrementally process files, relying on the inode might not be such a good idea ? I have already identified that truncating a file doesn't change an inode (obviously !), but if there are additional scenarios where removing a file could result in a new file with same inode then perhaps I need to think again. – Little Code Sep 02 '20 at 11:53
  • It's unclear why you would want to use the inode anyway. Once you open a file it's not going anywhere. – Michael Hampton Sep 02 '20 at 15:41

0 Answers0