changing inode number as a result of modification of a file
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. Code:
ln myfile myfile.tmp123 [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. |
Quote:
Quote:
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. |
All times are GMT -5. The time now is 03:54 PM. |