[PATCH 2/2] Re: Temporarily delete old-style lock files

[Sebastian Spaeth]

On Mon, 15 Aug 2011 13:55:30 +0200, Nicolas Sebrecht wrote:
> There two kind of locks we are mixing:
> - the lock preventing offlineimap to start;
> - the lock preventing concurrent modifications in the same area.
> 
> Both were mixed up because it made sense. This is no more true with a
> per-account lock.
> 
> So, the new version must take care for the old lock while starting up an
> instance. Once started, ignore the old lock for modifications; set up
> and deal with the new "per-account" system.
> 
> The new locking system must declare it is running with the new locking
> system so that other new instances can be launched while old lock is set
> up.

Pfeww, I just tried. This is getting really complex.

1) old offlineimap always creates and exclusively locks
   ~/.offlineimap/lock while it runs.
2) new offlineimap will have to do the same to prevent old offlineimap
   from running when new ones run.
3) new offlineimap will have to write something like
   ~/.offlineimap/accountlock to let other new offlineimaps know that we
   are using new-style locking. It ignores old-style locks when the
   new-style lockfile exists.
4) In addition new offlineimap will have to create per-account locks.

Doing all this without race conditions is something that will not be
trivial. The exploitable window will be quite small, but it will exist
unless we do really smart stuff.

How about: 1) We start writing out the new per-account lock but we still
honor the old global lock.

We keep this dual system for 1-2 stable releases before ditching the old
lock system. This way we can still keep subsequent stable releases
running without danger. At some point we can then say: "offlineimap 6.3.10
will not honor the locking system of 6.3.5 anymore". This sounds like a
more backward-compatible approach without too much ballast.

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110815/e8d5910f/attachment-0001.sig>