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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
