sync_client bails when encountering a deleted message

David Carter dpc22 at cam.ac.uk
Sun May 13 06:39:51 EDT 2007


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: David.Carter at ucs.cam.ac.uk
University Computing Service,            Phone: (01223) 334502
New Museums Site, Pembroke Street,       Fax:   (01223) 334679
Cambridge UK. CB2 3QH.


More information about the Cyrus-devel mailing list