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

[Sebastian Spaeth]

On Fri, 19 Aug 2011 18:35:23 +0200, Nicolas Sebrecht <nicolas.s-dev at laposte.net> wrote:
> > 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.

1st we check for new-style locks. None there, next, we check for
old-style lock. But in the mean time, we could have another new-style
lock created, etc. Just locks of little places between testing for and
creating the various lock files which makes me a little nervous. 

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

This strategy is much easier to implement and I propose a patch series
that does:
#1 Implement new-per account lock, ripping out the old lock system
#2 Re-implement old-style lock with comments, in a few versions this
   patch needs to be reverted to simply ditch the old lock system and
   just have the new one. We also throw an OfflineImap Error when we
   detect such a lock.
#3 Improve the error logging when we detect an OfflineImapError in the
   main thread by using our new ui.error() infrastructure.

We can leave that in for 1-2 releases and then release a 6.4 or 7.0 or
whatever and ditch the legacy locking support.

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/20110822/2941c180/attachment-0001.sig>