Elektrified X.org released (was: X configuration paradigm, and a proposal)
Neal D. Becker
ndbecker2 at verizon.net
Tue Nov 30 19:55:49 UTC 2004
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
More information about the fedora-devel-list
mailing list