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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
