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