Sean Middleditch wrote: > On Tue, 2004-11-30 at 14:24 -0500, Neal D. Becker wrote: >> Sean Middleditch wrote: >> >> [...] >> > So far as implementation, this really is easy even with a (single) >> > file- >> > based backend. Robustness might take some work, but the basics are >> > easy. You simply keep a list of all they keys that have been set, and >> > when the Commit command comes along, lock the file(s) in question and >> > modify them. On Rollback, just "forget" all the key changes that >> > haven't been committed yet. Basically the hard part for the simple >> > file backend is getting the commit to stay atomic on errors when you >> > use >> > multiple files. If you have multiple files being changed, I don't >> > believe it's actually possible to be 100% atomic - you can reduce the >> > chances of something breaking, but there will always be various race >> > conditions in regards to when errors occur that could leave you in a >> > half-committed state. >> > >> >> rename is atomic. You can always use this fact if you need to. > > Yes. That doesn't help with the problem of making atomic commits to > *multiple* files. You would have to perform multiple renames, of which > some may succeed and others may fail for any of a number of reasons, and > then you can't necessarily undo the ones you already did. Unless there > is a way to do an atomic rename of multiple files, my point definitely > still stands - multiple files cannot be modified atomically. > >> Are you sure? What if you: 1) duplicate the directory (using hardlinks to files) 2) atomic rename directory
