Linux - KernelThis forum is for all discussion relating to the Linux kernel.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

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 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

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.

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 ?
*/

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 ?

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.

Quote:

Originally Posted by Rohan Waghere

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 ?
*/

For maximum safety, the way an editor normally updates an existing file is:

Create a new file (with a temporary name) with the new content,

Check that the new file was written without error,

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.