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.