Re: RFC: O_PONIES semantics (well O_REWRITE)

[Rik van Riel <riel@redhat.com>]

Andreas Dilger wrote:
> On Jun 10, 2009  21:03 -0400, Rik van Riel wrote:
>> The semantics for O_REWRITE would be:
>>
>> 1) When opening a file O_REWRITE, the file handle points at
>>    a freshly allocated, empty file.  The original file is
>>    still available to programs that open the file without
>>    O_REWRITE.
>>
>> 2) O_REWRITE can only be used in conjunction with O_WRONLY,
>>    because the file descriptor is not associated with the
>>    original file (which has data), but with an empty inode.
>>
>> 3) The code that implements O_REWRITE (kernel?  glibc?)
>>    makes sure that:
>>    - the new file is on the same filesystem as the original file
>>    - the new file is not linked (so it is automatically freed
>>      after a process or system crash)
>>    - the new file's ownership, permissions and extended attributes
>>      match that of the original file
>>
>> 4) The application that opens a file O_REWRITE is required
>>    to rewrite the entire file.
> 
> This is all essentially open(O_CREAT|O_TRUNC|O_WRONLY)

With one big difference.

open(~/.myprog/myprog.conf, O_REWRITE|O_WRONLY) does not
truncate the inode which myprog.conf lives in currently,
but it opens a new inode instead.

This means that the old ~/.myprog/myprog.conf still exists,
and will continue to exist until the program closes the
O_REWRITE file handle - at which point the new contents
will be attached to the filename.

-- 
All rights reversed.