On Sat, 12 May 2007, John Capo wrote:
upload_message_work() returns IMAP_IOERROR when it can't map the message
being uploaded due to a race between reading the index and actually
doing the upload work.
delayed_expunge greatly reduces the scope for this race condition.
Quietly turning mailbox delete into mailbox rename also helped in 2.1.X as
sync_client chdir()s into the working directory. However in 2.3.X
mailbox_map_message() constructs a full path for each new message.
Its been a long time now since I've had a sync_client bail out. I'm aware
that people running 2.3 have been having a less fun time.
upload_message_work() returns with these items in the stream to the
server. [...] The server is expecting the header_size to arrive next but
most anything can arrive depending on what client work is left to do.
I agree that breaking off halfway through a command is really bad.
A quick scan through the code suggests that UPLOAD is the only awkward
case, simply because it is much more involved than the other commands.
A really ugly hack is to and fake up a message and send that to
keep the stream in sync. The fake message is deleted from the
replica on the next MAILBOX command.
A fake message is the simplest solution to this specific problem. However,
there should really be some similar protection in the two parent routines,
upload_message_list() and upload_messages_from().
Sending \r\n and then waiting for the server to moan about an incomplete
UPLOAD command should be enough for the two ends to resynchronise
correctly in all cases. The server won't commit anything (though any
complete messages should get cached on the server sync. queue).
It would make sense to try and factor this out as a common error handling
case in sync_client. I'm off for a couple of days, but may have a go at
implementing this next week unless someone has a better idea.
--
David Carter Email: [EMAIL PROTECTED]
University Computing Service, Phone: (01223) 334502
New Museums Site, Pembroke Street, Fax: (01223) 334679
Cambridge UK. CB2 3QH.
