[PATCH 2/2] Re: Temporarily delete old-style lock files
nicolas.s-dev at laposte.net
Mon Aug 15 12:55:30 BST 2011
On Mon, Aug 15, 2011 at 01:21:37PM +0200, Sebastian Spaeth wrote:
> Old versions are not bad at unlocking, they just leave the lock file
> around forever (which doesn't hurt). This patch was just cleaning up the
> old lock file by deleting it.
> The only problem I see is that if we want to deal with both the old
> "global" and the new "per-account" system, we need to implement both and
> a) take the global lock AND b) the per-account lock.
> In this case, our shiny per-account code wouldn't be of any use as we
> are effectively back to the global lock.
> Do I make sense?
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
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
... Or, make it evident in the documentation that the new and old
locking system don't check for each other while starting; which could
_strongly_ mess up their data if accidently done. This is the option I'd
rather not worry our users with.
More information about the OfflineIMAP-project