CORRECT PATCH Re: sync_client bails when encountering a deleted message

[John Capo]

Quoting Ken Murchison (murch at andrew.cmu.edu):
> John Capo wrote:
> >Quoting Ken Murchison (murch at andrew.cmu.edu):
> >>Ken Murchison wrote:
> >>>Obviously, the chances of header_size being 0xdeadbeef is remote, but it 
> >>>is possible.  Would it make more sense to use ULONG_MAX as the "failure 
> >>>size"?
> >>Or better yet, how about just using 0 (zero)?  IIRC, RFC2822 stipulates 
> >>that the message header has to be non-zero (Date and From are mandatory)
> >
> >I have seen zero size messages created with IMAP uploads from desktop
> >clients.  This is probably a bug elsewhere.  I do not know if the
> >zero size messages were replicated.
> >
> >Sending more than one magic number would be the safest way. The
> >value of the second magic number could be used to signal other
> >conditions if needed.  I can't imagine what that would be other
> >than aborting the upload.  Two ULONG_MAX is a row can't be a valid
> >message.
> 
> After thinking about this some more,do we even need a magic number?  If 
> we don't send anything after the flags list, shouldn't this be enough to 
> signal that we have an invalid/missing message?

We still need to see what's next in the stream if anything.  When
upload_message_work() returns due to not being able to open a
message, the next byte in the stream should be the first letter of
a command.  Testing the next character returned by prot_getc() for
alpha or numeric could signal an abort.  If its alpha then its the
next command.  If its numeric then its the header size.  prot_ungetc()
the character and return or fetch the header size from the stream
and continue.

If the connection is closed prot_getc() would return EOF and
cmd_upload() would return to cmd_loop().  cmd_loop() would also see
EOF since its a flag in the prot structure.  Not sure how to test
the EOF case.

I'll see if the basic idea works later today.

John Capo





> 
> -- 
> Kenneth Murchison
> Systems Programmer
> Project Cyrus Developer/Maintainer
> Carnegie Mellon University