Reformatted excerpts from Ben Walton's message of 2009-05-06: > The next option is to play with locks, but that's not straight forward > at all.
This is my favorite option, because sup-sync-back also has to do mbox locking, so I don't think we can avoid the issue in general. > Dovecot, as an example, allows a configuration knob for the admin to > set the order in which the different mechanisms are used. This works > as long as all of the mbox consumers use the same sequence. There is > still lots of room for error here (NFS, etc). Currently sup-sync-back just says, "hey, you can use this program /usr/bin/dotlockfile if you have it" and pushes the details of locking to that. I think that's at least a vaguely reasonable approach. Ideally it would be more configurable, would fall back to other locking programs, etc., but I think it's significantly better than not doing any locking at all. (Eventually these two mbox writers should share the same locking code, but don't feel obligated to refactor as part of your patch if it's already getting too hairy.) -- William <wmorgan-...@masanjin.net> _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
