Yes I have used the stat command to determine Inode.
The problem is when I modify the file, the inode changes , even though it is supposed to be the same.
If there are multiple links to a file, vi file should not change the i-node number. If there is only one link to a file and you make any changes to the file using vi , it is more efficient to rename the temp file to the final resting place rather than copy the temp file onto the original file and then remove the temp file.
Why do you care if the i-node number changes? Why isn't the file's name ( a.txt ) sufficient for identifying the file?
(Note that ls -i and ls -li will also give you the i-node number even on systems that don't have the stat utility.)
Hey thanks,
I need a way to uniquely determine if a log file is rotated/rolled up or not.
In case it is rotated, the original log file (a.log) will be renamed to a.log.1 and a new a.log is created. So the new a.log will have a different inode no. This way I can determine if a log file has been rotated or not. However ,if the inode no changes for every modification I cannot check if a file is rotated/rolled up or not.
Can you think of some other file attribute that will help me uniquely identify this?
Is there a way to keep the inode constant?
This is just a wild guess - I can not reproduce your findings on my systems and I have no gedit available.
vi usually creates a swap file which you work on instead of the original file. Maybe your vi-implementation replaces the original file with the swap file. vim 7.3 offers the -n flag to disallow the creation of the swap file (:set uc=0 should do the same).
Though this problem reproduces with VI and gedit, this happens when we perform file handling operations using java C and perl. In these cases, the files are modified by the program. Do you think the issue is more related to an OS ?
So say, a java program creates and modifies a file, with each modification the inode changes. This happens not just in my machine but in multiple machines. Can we work around this behavior somehow?
I think what is meant is what is the filesystem type, ext2, ext3, ext4, jfs, zfs, ufs, adfs etc.
Anyway, in answer to your original question, "Why does the Inode number change." It is likely that this is due to the editor, as they quite often work with "shadow copies" of the file you are editing, and the new copy replaces the original file.
I don't use Gedit, however if you open a file in gedit and while it is open have a look in the directory to see if there are other copies of the file as follows;
Modifying an existing file does not change the inode number. The code you're using rewrites the file to a new one, then rename()'s the new file with the old name.
How do you stop that? You don't do it.
If your log file inodes are changing, I'd say the problem is, "Who is editing the log files?" There's auditing to figure that out.
It means the file is being replaced by another file, not that the inode on the same file is "changing" somehow. Prevent the directory from being written to by the processes -- to prevent the moving, creation, and deletion of files -- will prevent the inode from "changing" -- by stopping these things from working. The file can still be overwritten.
If you want the inode to remain the same, don't use anything that replaces it. If you use stream commands to alter the file, don't edit "in place" or such -- redirect them to a temp file, then cat the new file over the original. To edit, copy to a temp file, edit the temp file, then cat the temp file over the original. I think this is what commands like crontab -e and visudo do.