On Thu, 2009-06-11 at 10:06 -0400, Rik van Riel wrote: > 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. How is this any different than just having your application use mkostemp() to create a temporary dot file, then renaming it when done writing? Trond -- 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
