I should include: the plan to fix this is to have intent logging in mailboxes.db - so we'll create a record for the destination name with a flag marking the intent to rename, such that you can't possibly create a rename loop.
Bron. On Thu, Sep 3, 2015, at 22:42, Bron Gondwana wrote: > IOERROR: failed to create fastmail.com!user.REDACTED.#calendars (Mailbox is > locked) > > We get these occasionally, and I wondered why until just now, when I > remembered... > > The initial CREATE or RENAME lock.. it's a mboxname_lock EXCLUSIVE, and it's > taken with nowait, and error if exists. It needs to, because the source > mailbox is locked, and you need to break a lock loop if you issued rename A > => B and rename B => A in parallel. > > So it was assumed as being not a problem, because you'd never try to create > the same name twice concurrently. The name didn't exist before, so nobody > will be looking at it. > > When I say "it was assumed", I mean that I assumed. In 2009 some time. > > But that's not true when you're autocreating the same name when you try to > read something. Anything. > > In fact, the way that the parser works, you wind up doing it for any http > request. So you get a race between two processes, one loses, logs this. > > We should probably fix this :) > > Bron. > > > > -- > Bron Gondwana > br...@fastmail.fm -- Bron Gondwana br...@fastmail.fm
