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

[Nicolas Sebrecht]

On Mon, Aug 15, 2011 at 02:42:18PM +0200, Sebastian Spaeth wrote:
> 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.

Yes, this is what I had in mind.

> 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.

I'm not seeing possible race conditions in the above.

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

I don't see the big difference with above. :-/

> 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.

I'm fine with that, too. I have in mind to move to 6.4 or 7.0 (maybe
changing releases for X.Y). I still wait because I'd like a test suites.
It would be also the time to do such lock migration.

-- 
Nicolas Sebrecht