FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EXT3 Users

 
 
LinkBack Thread Tools
 
Old 11-26-2008, 03:40 AM
"lakshmi pathi"
 
Default A Question on inode - ext3FS

I have noticed that whenever you edit a file content,a new inode
number is assigned with the File.
But Sometime file changes the inode number,Sometimes it remains as older inode.

Can anyone please let know the concept behind this - modifing content
changes the file's inode but not all the time?

I'm using Fedora 7 with ext3 file system. (Kernel : 2.6.25.4)

Cheers,
Lakshmipathi.G

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 11-26-2008, 04:01 AM
Daniel Pittman
 
Default A Question on inode - ext3FS

"lakshmi pathi" <lakshmipathi.g@gmail.com> writes:

> I have noticed that whenever you edit a file content,a new inode
> number is assigned with the File.

No, it never is.

> But Sometime file changes the inode number,Sometimes it remains as
> older inode.

Sometimes your editor creates a *new* file, which has a new inode
number, and replaces the original file with it. Other times the content
is edited and now new file is created.

Regards,
Daniel

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 11-26-2008, 04:02 AM
"Stephen Samuel"
 
Default A Question on inode - ext3FS

It's an application issue.* It has to do with how the file is updated.
There are two ways for an editor to update a file:
* write to the file in place, (nostly done with simple appends) or
* write a new version of the file (with a temporary name), then rename the temporary file to replace the old one.


The first method only modifies the existing file, so the Inode number changes the same.

The secondmethod creates a new file (with a different inode number) and then the new file (with the new inode number) replaces the old file.


THe main advantage of the second method is that it's atomic. Either the file is replaced, or it isn't. Thus other users/programs which accesss the file never see intermediate results.* (also the case if the program dies, or the system is reset).


The first method has the advantage that the inode# stays the same, and so any programs which had the old file open will see the updates.* The disadvantate is that if anything goes wrong in the middle of the update, the file could end up in an partial update state.


Remember, the file is nothing more than a collection of bytes.* There's no way to insert a character or two in the middle of the file. You then have to rewrite the entire file from that point on.


On Tue, Nov 25, 2008 at 8:40 PM, lakshmi pathi <lakshmipathi.g@gmail.com> wrote:

I have noticed that whenever you edit a file content,a new inode

number is assigned with the File.

But Sometime file changes the inode number,Sometimes it remains as older inode.



Can anyone please let know the concept behind this - modifing content

changes the file's inode but not all the time?



I'm using Fedora 7 *with ext3 file system. (Kernel : 2.6.25.4)

--
Stephen Samuel http://www.bcgreen.com

778-861-7641

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 11-26-2008, 06:38 AM
"Jordi Prats"
 
Default A Question on inode - ext3FS

2008/11/26 Stephen Samuel <darkonc@gmail.com>:
> It's an application issue. It has to do with how the file is updated.
> There are two ways for an editor to update a file:
> write to the file in place, (nostly done with simple appends) or
> write a new version of the file (with a temporary name), then rename the
> temporary file to replace the old one.
>
> The first method only modifies the existing file, so the Inode number
> changes the same.
>
> The secondmethod creates a new file (with a different inode number) and then
> the new file (with the new inode number) replaces the old file.
>
> THe main advantage of the second method is that it's atomic. Either the file
> is replaced, or it isn't. Thus other users/programs which accesss the file
> never see intermediate results. (also the case if the program dies, or the
> system is reset).


Just curious...How is done that?There's a system call to do this replacement?

Thanks!

> The first method has the advantage that the inode# stays the same, and so
> any programs which had the old file open will see the updates. The
> disadvantate is that if anything goes wrong in the middle of the update, the
> file could end up in an partial update state.
>
> Remember, the file is nothing more than a collection of bytes. There's no
> way to insert a character or two in the middle of the file. You then have to
> rewrite the entire file from that point on.
>
> On Tue, Nov 25, 2008 at 8:40 PM, lakshmi pathi <lakshmipathi.g@gmail.com>
> wrote:
>>
>> I have noticed that whenever you edit a file content,a new inode
>> number is assigned with the File.
>> But Sometime file changes the inode number,Sometimes it remains as older
>> inode.
>>
>> Can anyone please let know the concept behind this - modifing content
>> changes the file's inode but not all the time?
>>
>> I'm using Fedora 7 with ext3 file system. (Kernel : 2.6.25.4)
>
> --
> Stephen Samuel http://www.bcgreen.com
> 778-861-7641
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users@redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
>



--
Jordi

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 11-26-2008, 06:59 AM
Theodore Tso
 
Default A Question on inode - ext3FS

On Wed, Nov 26, 2008 at 08:38:46AM +0100, Jordi Prats wrote:
> > THe main advantage of the second method is that it's atomic. Either the file
> > is replaced, or it isn't. Thus other users/programs which accesss the file
> > never see intermediate results. (also the case if the program dies, or the
> > system is reset).
>
> Just curious...How is done that?There's a system call to do this replacement?
>

Yes. It's called rename(). Run "man 2 rename" to see its man page.

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 11-27-2008, 02:17 AM
"lakshmi pathi"
 
Default A Question on inode - ext3FS

>It's an application issue.

Thank you all.Here is detailed info. of what i did:

I have created two files file7 and file8 using vi :
[root@localhost ~]# vi file7
[root@localhost ~]# vi file8

and added content "this "
and here is the ls output :

[root@localhost ~]# ls -il file7
6933339 -rw-r--r-- 1 root root 5 2008-11-26 20:56 file7
[root@localhost ~]# ls -il file8
6933340 -rw-r--r-- 1 root root 5 2008-11-26 20:56 file8

Now i changed the permission for file8 :
[root@localhost ~]# chmod 777 file8
[root@localhost ~]# ls -il file8
6933340 -rwxrwxrwx 1 root root 5 2008-11-26 20:56 file8


(After changing chmod inode remains same,since file8 data block are
not modified.)

Now i added / appended new character to both files using vi command

[root@localhost ~]# vi file7
[root@localhost ~]# ls -il file7
6933311 -rw-r--r-- 1 root root 7 2008-11-26 20:58 file7

As expected size and timestamp are updated . And along with inode
numbers.(Earlier it was 6933339 -- now it is 6933311)

[root@localhost ~]# vi file8
[root@localhost ~]# ls -il file8
6933340 -rwxrwxrwx 1 root root 7 2008-11-26 20:58 file8
[root@localhost ~]#

But see here ,the inode remains the same(6933340) - though the content
is modified

Is

Now i changed the file mode to 644 :

[root@localhost ~]# chmod 644 file8
[root@localhost ~]# ls -il file8
6933340 -rw-r--r-- 1 root root 7 2008-11-26 20:58 file8

and appended a new character

[root@localhost ~]# ls -il file8
6933451 -rw-r--r-- 1 root root 8 2008-11-26 21:07 file8
...now the inode is also changed.(from 6933340 to 6933451)


My doubts are :
1)Does files permission play any role in determining inode number of
file when it's getting editted?
2)How application can decide on whether new inode / older inode,so far
i thought it depends on functionality of filesystem/kernel.
(I found edit files using different application like gedit doesn't
change the inode.but vi changes inodes)

(I have written little ext3 undelete tools,understanding these
concepts will help me lot,If my assumption are wrong please correct
me.)

--
Cheers,
Lakshmipathi.G

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 11-27-2008, 03:26 AM
Theodore Tso
 
Default A Question on inode - ext3FS

On Thu, Nov 27, 2008 at 03:17:56AM +0000, lakshmi pathi wrote:
>
> My doubts are :
> 1)Does files permission play any role in determining inode number of
> file when it's getting editted?

It depends on the application.

> 2)How application can decide on whether new inode / older inode,so far
> i thought it depends on functionality of filesystem/kernel.

It depends on the application.

If the application does this when it writes the file:

fd = open("filename", O_WRONLY|O_TRUNC);
write(fd, buf, bufsize);
close(fd);

Then it will have the same inode number. Unfortunately, if your
machine crashes (at exactly the wrong moment, i.e., right after the
open has truncated the original file) while it is writing out
Ph.D. thesis for which you have been spending the last 2 years
writing, and you didn't keep any backups --- well, someone stupid
enough not to do backups of their thesis probably doesn't deserve a
Ph.D. :-)


If the application does this when it writes the file:

fd = open("filename.new", O_WRONLY|O_TRUNCATE);
write(fd, buf, bufsize);
close(fd);
rename("filename.new", "filename);

Then if you crash in the middle, you might lose what you had written
in the last editing session, but at least the version of your file
from the previous editing session is still safe, since we first write
the new file as "filename.new" (and in the competently written version
of the editor, every single system call will have appropriate error
checking, which I've omitted here for clarity, but which is important
since you want to make sure you know the file was correctly written
and not truncated due to NFS server failing, or quota issues, or the
disk filling, etc.)

Note that in safe and sane way of doing things, you *will* get a new
inode number --- it's unavoidable, because the old and new versions of
the file co-exist at the same time for a brief period of time, so of
course the new version of the file will have a new inode number. (As
opposed to the insane way of doing things, where for a brief period of
time, *no* copy of the content will exist on disk, and if you crash
then --- oh, well. But hey! For people who care about keeping the
same inode number, I guess that can be your consolation....)

Some editors can be configurable which way that they do things.

Also, some editors might normally prefer to use the O_TRUNC method
(maybe because out of some misguided desire to keep the inode number
the same, or because they don't want to bother with copying extended
attributes or because they are worried about disk space, so they want
to blow away the original file contents with the open (O_TRUNC), and
then write the new file contents). However, for those application, if
the file permissions make the file read-only, such that opening the
file for writing would fail, it's possible such an insane application
might then fall back to the safe and sane way of doing things. But
that's purely an application decision --- the application could
decide, if it is determined to do something as unsafe and risky as
unprotected sex with someone they just met at some skanky bar as a
one-night stand, the application could just forcibly change the
permissions on the file, or just unlink the file file first.

The bottom line is that it has ****NOTHING**** to do with the
filesystem/kernel. It all has to do with whether the application
writer cares about risking the user's data or not.

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 11-27-2008, 09:03 AM
"lakshmi pathi"
 
Default A Question on inode - ext3FS

Thanks a lot for your detailed reply with sample codes

--
Cheers,
Lakshmipathi.G



On Thu, Nov 27, 2008 at 9:56 AM, Theodore Tso <tytso@mit.edu> wrote:
> On Thu, Nov 27, 2008 at 03:17:56AM +0000, lakshmi pathi wrote:
>>
>> My doubts are :
>> 1)Does files permission play any role in determining inode number of
>> file when it's getting editted?
>
> It depends on the application.
>
>> 2)How application can decide on whether new inode / older inode,so far
>> i thought it depends on functionality of filesystem/kernel.
>
> It depends on the application.
>
> If the application does this when it writes the file:
>
> fd = open("filename", O_WRONLY|O_TRUNC);
> write(fd, buf, bufsize);
> close(fd);
>
> Then it will have the same inode number. Unfortunately, if your
> machine crashes (at exactly the wrong moment, i.e., right after the
> open has truncated the original file) while it is writing out
> Ph.D. thesis for which you have been spending the last 2 years
> writing, and you didn't keep any backups --- well, someone stupid
> enough not to do backups of their thesis probably doesn't deserve a
> Ph.D. :-)
>
>
> If the application does this when it writes the file:
>
> fd = open("filename.new", O_WRONLY|O_TRUNCATE);
> write(fd, buf, bufsize);
> close(fd);
> rename("filename.new", "filename);
>
> Then if you crash in the middle, you might lose what you had written
> in the last editing session, but at least the version of your file
> from the previous editing session is still safe, since we first write
> the new file as "filename.new" (and in the competently written version
> of the editor, every single system call will have appropriate error
> checking, which I've omitted here for clarity, but which is important
> since you want to make sure you know the file was correctly written
> and not truncated due to NFS server failing, or quota issues, or the
> disk filling, etc.)
>
> Note that in safe and sane way of doing things, you *will* get a new
> inode number --- it's unavoidable, because the old and new versions of
> the file co-exist at the same time for a brief period of time, so of
> course the new version of the file will have a new inode number. (As
> opposed to the insane way of doing things, where for a brief period of
> time, *no* copy of the content will exist on disk, and if you crash
> then --- oh, well. But hey! For people who care about keeping the
> same inode number, I guess that can be your consolation....)
>
> Some editors can be configurable which way that they do things.
>
> Also, some editors might normally prefer to use the O_TRUNC method
> (maybe because out of some misguided desire to keep the inode number
> the same, or because they don't want to bother with copying extended
> attributes or because they are worried about disk space, so they want
> to blow away the original file contents with the open (O_TRUNC), and
> then write the new file contents). However, for those application, if
> the file permissions make the file read-only, such that opening the
> file for writing would fail, it's possible such an insane application
> might then fall back to the safe and sane way of doing things. But
> that's purely an application decision --- the application could
> decide, if it is determined to do something as unsafe and risky as
> unprotected sex with someone they just met at some skanky bar as a
> one-night stand, the application could just forcibly change the
> permissions on the file, or just unlink the file file first.
>
> The bottom line is that it has ****NOTHING**** to do with the
> filesystem/kernel. It all has to do with whether the application
> writer cares about risking the user's data or not.
>
> - Ted
>

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 

Thread Tools




All times are GMT. The time now is 02:46 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org