John Capo wrote:
Quoting Ken Murchison ([EMAIL PROTECTED]):
John Capo wrote:
Quoting Ken Murchison ([EMAIL PROTECTED]):
John Capo wrote:
Quoting John Capo ([EMAIL PROTECTED]):
Quoting Ken Murchison ([EMAIL PROTECTED]):
I don't think I was clear. With my proposal, we're well past
"UPDATE". I'm talking about cutting the command short after
"(<flags>)". No header_size or anything after.
I guess I don't understand what you mean.
It sure looks to me like cmd_upload() has to detect that the header
size it is waiting for will not arrive and recover gracefully rather
than sending a BAD that the client sees as the response for its
next command. Patch attached.
The server needs to push the character back except on EOF, grrrr.
Here's what I was thinking. We might be able to bump the cache flush
down to parse_err, but I'm not sure if this is correct/suboptimal for
SIMPLE.
Ths might work if you add an eatline() in the client before returning.
The BAD response from the server must be discarded somehow or the
BAD response will be seen by the client as the response to the next
client command. It seems to me that no response is needed since
the client is not expecting one.
Here is an untested patch which SHOULD allow the client to abort the
UPLOAD, with the server successfully accepting the messages transmitted
up to the abort.
Thoughts?
This patch works fine on my test box when a message disappears. I
did not test folders disappearing but that should work too. Next
week I will update my production servers to use this patch instead
of my fix.
I have one customer that gets 5K+ messages daily with 350+ archive
folders. This customer is a really good stress test for the
sync_client.
Thanks John. I'll commit this to CVS.
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
