Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Posted Sep 11, 2011 0:12 UTC (Sun) by butlerm (subscriber, #13312)
I mention locking because it is the most common way to implement atomic commit semantics, from the perspective of all other processes. Your idea makes great sense as long as you have multiversion read concurrency, so that existing openers can see an old, read only version of the file indefinitely.
POSIX simply has a different solution for that, as I am sure you know - the name / inode distinction, which allows you to delete a file, or rename replace it with a new version without locking other processes out, waiting, or disturbing existing openers.
It is unfortunate of course that there is no standard call to clone an existing file's extended attributes and security context for use in a rename replace transaction - perhaps one should be added, it would be a worthwhile enhancement. Hating UNIX when it is vastly superior to the most widely distributed alternative in this respect seems a bit pointless to me.
Posted Sep 11, 2011 16:00 UTC (Sun) by sionescu (subscriber, #59410)
open(path, O_REPLACE) only allocates a new inode
close(fd, CLOSE_COMMIT) atomically replaces the reference to the old inode with the new inode(just like rename) copying all metadata except for the (a|c|m)time, then calls fsync()
easy, isn't it ?
Posted Sep 11, 2011 20:45 UTC (Sun) by nix (subscriber, #2304)
Posted Sep 11, 2011 21:10 UTC (Sun) by sionescu (subscriber, #59410)
The new syscall could be called close2, adding a "flags" parameter - in the spirit of accept4() et al.
Posted Sep 11, 2011 21:52 UTC (Sun) by nix (subscriber, #2304)
Posted Sep 11, 2011 22:14 UTC (Sun) by sionescu (subscriber, #59410)
Posted Sep 11, 2011 23:51 UTC (Sun) by nix (subscriber, #2304)
Posted Sep 23, 2011 0:59 UTC (Fri) by spitzak (guest, #4593)
There may be a need to somehow "abort" the file so that it is as though you never started writing it. But it may be sufficient to do this if the process owning the fd exits without calling close().
I very much disagree with others that say POSIX should be followed. The suggested method of writing a file is what is wanted in probably 95% of the time that files are written. It should be the basic operation, while "dynamic other processes can see the blocks change as I write them" is an extremely rare operation that should be the one requiring complex hacks.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds