<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span><br></span></div><div><br></div><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><font size="2" face="Arial"><b><span style="font-weight:bold;">Sebastian wrote:</span></b></font><br>On Tue, 30 Aug 2011 11:20:58 -0700 (PDT), chris coleman wrote:<br>> After a crash (steps to reproduce: disconnect the internet during the middle of a run), it leaves lock files on the disk. <br><br>Current OfflineImap always leaves the lock file existing, it just<br>request an exclusive lock via fcntl when it wants to take it. This way<br>the lock is going away when the process has gone away even if the lock<br>file is still there.<br><br>I have still the patch series to introduce per-account locking (and it<br>will
clean up locks when it doesn't crash), but the locking method will<br>be the same: taking an exclusive lock.<br><br>If it doesn't work after a "crash" I would be very surprised (I believe<br>you though :-)). The locking code hasn't changed in ages.<br><br><br><br>If I understand correctly, the lock is a secondary artifact of the actual exclusive lock object, which exists inside fcntl, and when our offlineimap python process crashes, the lock object is unlocked, and the file is also unlocked.<br><br>To me, this implies that, on startup of offlineimap, the initialization procedure should be updated to try to delete the lock file(s), and if succesful, this proves that there is no currently running offlineimap process, so by deleting the lock file(s) we just effectively did some garbage collection. <br><br>But if deleting those lock file(s) fails, then this proves there is another offlineimap process currently running, so the code should exit with
this info message.<br><br>Chris<br></div></div></div></body></html>