Query :

I am trying to modify write system call for ext3 file system.

I need to store the inode number of a file inside it while it is being written to disk. Next time that inode number will be used to verify the file's logical identity.

But i constantly get a problem that is when the inode number of the file changes after modification in it. So can anyone tell me when and how the inode number of a file changes exactly?

I read in the book 'Design of unix operating system', the topic "Releasing the inode" that a new inode gets assigned and previous one is just "dirtied" and released but couldn't actually trace its actual working inside the write system cal., to answer myself 'why it changes?'.

If anyone knows this please provide detailed explanation with the function where the inode number changes.

I also found few links on Google but didn't really help my cause.

Regards,
Rohan Waghere.

I don't know where you read that, but it's not something that happens as a direct consequence of writing to a file. The change of inode number comes about from the common practice of most editors to write the changed version to a temporary file and then rename the temp file over the original file name, thus greatly reducing the chances of an error causing both the old and new versions to be lost.

One way to avoid that behavior is simply to make a second hard link to the original file.A well behaved editor will then write directly back to the original file in order to avoid breaking the hard link. You can delete that extra link afterward, if you like.

[edit] Of course if you have control of the program that is writing that file in the first place, it would be a lot simpler just to stat() the file after opening it and before writing anything, and get the inode number from the data returned.

Firstly thank you Sir for your reply!

My comments are inline:

I don't know where you read that, but it's not something that happens as a direct consequence of writing to a file. The change of inode number comes about from the common practice of most editors to write the changed version to a temporary file and then rename the temp file over the original file name, thus greatly reducing the chances of an error causing both the old and new versions to be lost.

/*
Sir what i came across in the study was as follows:
"When the kernel releases an inode, it decrements its in-core reference count. If the count drops to 0, the kernel writes the inode to disk if the in-core copy differs from the disk copy. They differ if the file data has changed, if the file access time has changed, or if the file owner or access permissions have changed. The kernel places the inode on the free list of inodes, effectively caching the inode in case it is needed again soon. The kernel may also release all data blocks associated with the file and free the inode if the number of links to the file is 0."

So, Sir at this point are we on the same track ?
*/

One way to avoid that behavior is simply to make a second hard link to the original file.
Code:
ln myfile myfile.tmp123
A well behaved editor will then write directly back to the original file in order to avoid breaking the hard link. You can delete that extra link afterward, if you like.

/*
And here i am getting what you are saying but still will you please elaborate a bit ?
*/

Regards,
Rohan Waghere.

Not really. That paragraph is about what happens when the counter for the number of references that currently running processes have to a file goes to zero, i.e., no process has the file open, mmapped, or (for a directory) has it as its CWD. At that time, the inode will be written to disk if anything in the inode has changed from what is already on the disk. The final sentence says that this is also the time when a file with no remaining directory links would have its data blocks released and the inode freed for reuse. None of that has anything to do with writing to a file except insofar as a write would be one of the things that would cause the inode contents to change. Note especially that this is a change to the inode contents, not a change to the inode number.
For maximum safety, the way an editor normally updates an existing file is:

1. Create a new file (with a temporary name) with the new content,
2. Check that the new file was written without error,
3. Use the rename() system call to atomically replace the inode number in the old directory entry with the inode number for the new file, and then delete the temporary name link.

Notice that the updated file will have an inode number different from the original.

Now, for a file with multiple hard links, that procedure leaves all of the other links pointing to the original inode and thus the original content. A well behaved editor will recognize that this is almost never the desired result, and, for a multi-link file will, instead of creating a temporary file, simply write directly to the original file, accepting the hopefully small risk that an error during that writing might leave you with nothing, or that some other process that happened to be reading that file while it was being written might receive some garbled mix of old and new content. Simply writing to the original file will not affect its inode number, and you can take advantage of that for what you are trying to do. Just make an extra link to the file while you are making your changes, and then delete that link when you are through.