1

I have 3 computers, A, B, and C, and I perform identical operating system and software installations on them. For any specific file on A, can I expect that same file on B and C to have the same inode number for its instance of that file?

Our intrusion detection system is set up by acquiring an initial file system image from A and then using that same file system image to do future comparisons against A, B, and C. I am new to the program, but it seems that this has worked in the past.

I don't know how the inode number sequencing works, so I'm guessing it just starts at 1 and counts up for each file, or something similar. If that's the case, that's probably why file inode numbers have been consistent even across computers for us in the past - the same files were created in the same order. Though I'm not sure if we can always count on that.

However, now I am getting notifications of a few files changed, and for the first file I am looking into it is only the file inode number which has changed. I think someone reinstalled the operating system and software on the computer with the notifications.

Can file inode numbers be counted on to be the same across identical OS/software installs on different computers (or sequential re-installs on the same computer)?

If I were to acquire a new file system image from either A, B, or C, can I expect that to fix my "problem" (not even sure if it's a problem)?

I generally have access to only 1 or 2 of the computers at a time, so I cannot inspect A or C right now, and I do not know what their report would look like. I only know that the inode number of at least 1 file on computer B is not what was expected.

In this case, the operating system is QNX 6. For file system type, mount tells me that the /dev/hd file's are "on / type qnx4"... so file system type qnx4? I guess qnx has its own file system type? I didn't realize that. Or maybe that's no accurate. Other commands for checking file system type do not seem to exist on the computer.

Update: Apparently I was mistaken about something. Although our reference data on the original state of the file system does include files' inode numbers and I have the option to include that in the test, I was not supposed to include the inode data in this check that I described in the question, and "It worked in the past" is because of this. So I do not actually need what I have asked for here after all, sorry about that. I will leave this question open though since I still find it interesting and a partial answer has been started in the comments.

Improve this question
6
  • 1
    Related: How to keep i-node consistent across separate Filesystems
    – Kusalananda ♦
    Commented Aug 30, 2019 at 21:36
  • 1
    Even more related: Making bit identical ext2 filesystems
    – Kusalananda ♦
    Commented Aug 30, 2019 at 21:39
  • It would not be enough to know what Unix you use, it would also be necessary to know what type of filesystem you use. I know of no common filesystem on Unix that use sequential numbering of inodes. I also don't quite know what you mean by "sequential". Do you mean sequentially stored on disk or sequentially created? Have a look at the inodes of the files in few large directories, on the systems I use, some may look sequential, but there are often big jumps. In general, inodes between devices can not be expected to refer to the same files.
    – Kusalananda ♦
    Commented Aug 30, 2019 at 21:46
  • 1
    1) Will add to question. 2) By sequential, I mean the inode numbers for sequentially created files. For example, I did a test echo test1>test1 then echo test2>test2, and test2's inode number was 1 higher than test1's (ie: file1's: 1234, file2's: 1235) @Kusalananda Also, I will look into the links you provided. Thank you.
    – Aaron
    Commented Aug 30, 2019 at 22:13
  • I'm not using QNX so I cannot give you an answer, but IMHO it would be very foolish to rely on that. Something trivial like the installer parallelizing some ops, as in foo 2>log1 | bar 2>log2 may completely defeat it, since there's no telling in which order log1 and log2 will be created (trying that with watch(1) show that the two files will swap inodes quite frequently, the more busy the system, the faster ;-)).
    – user313992
    Commented Aug 31, 2019 at 1:21

1 Answer 1

Reset to default
2

[...] and I perform identical operating system and software installations on them.

For any specific file on A, can I expect that same file on B and C to have the same inode number for its instance of that file?

No, because I/O runs in parallel, and the order of I/O operations is not deterministic and affected by what the hardware does. The OS assigns inode numbers, and if some operations run in a different order on, say, system A and B, the OS could assign different inode numbers for the "same" file.

A similar artifact is that assignments in /dev/ are not guaranteed to be consistent across reboots, even on the same system: What is /dev/sdb now could have been /dev/sda on the last boot.

If I were to acquire a new file system image from either A, B, or C, can I expect that to fix my "problem" (not even sure if it's a problem)?

It's not a problem (unless you make it into one), and yes, if you copy over whole file system images, they'll have the same inode numbers.

Although our reference data on the original state of the file system does include files' inode numbers and I have the option to include that in the test, I was not supposed to include the inode data in this check that I described in the question,

Exactly. The answer is "no, you can't rely on it, and therefore you shouldn't test it, because then it becomes a problem."

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .