Quoting David Carter ([EMAIL PROTECTED]):
> On Sun, 5 Aug 2007, John Capo wrote:
>
> >My simple test is adding a sleep(10) in upload_message_work() and
> >logging that we are sleeping. I cause a new message to be appended to
> >the Sent folder. When I see the sleeping log entry I delete the me
On Sun, 5 Aug 2007, John Capo wrote:
My simple test is adding a sleep(10) in upload_message_work() and
logging that we are sleeping. I cause a new message to be appended to
the Sent folder. When I see the sleeping log entry I delete the message
that was just appended.
I have just tried the
Quoting John Capo ([EMAIL PROTECTED]):
> Quoting David Carter ([EMAIL PROTECTED]):
> > On Thu, 17 May 2007, Ken Murchison wrote:
> >
> > >Here is an untested patch which SHOULD allow the client to abort the
> > >UPLOAD, with the server successfully accepting the messages transmitted
> > >up to t
Quoting David Carter ([EMAIL PROTECTED]):
> On Thu, 17 May 2007, Ken Murchison wrote:
>
> >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?
>
> I believe that ther
On Thu, 17 May 2007, Ken Murchison wrote:
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?
I believe that there is a problem with this patch. Sorry that its taken
this lon
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".
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
> >
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 "()". No
On Tue, May 15, 2007 at 10:21:05AM -0400, John Capo wrote:
> Quoting Ken Murchison ([EMAIL PROTECTED]):
> > 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"?
>
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 "()". No
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 "()". No
> >
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 "()". No header_size or anything after.
I guess I don't understand wha
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 "()". No
> > header_size or anything after.
>
> I guess I don't understand what
gt; --
> Kenneth Murchison
> Systems Programmer
> Project Cyrus Developer/Maintainer
> Carnegie Mellon University
>
> -Original Message-
> From: "John Capo" <[EMAIL PROTECTED]>
> To: "Ken Murchison" <[EMAIL PROTECTED]>
> Cc: cyrus-de
intainer
Carnegie Mellon University
-Original Message-
From: "John Capo" <[EMAIL PROTECTED]>
To: "Ken Murchison" <[EMAIL PROTECTED]>
Cc: cyrus-devel@lists.andrew.cmu.edu
Sent: 5/15/07 3:34 PM
Subject: Re: CORRECT PATCH Re: sync_client bails when encountering a deleted
me
Quoting Ken Murchison ([EMAIL PROTECTED]):
> John Capo wrote:
> >Quoting Ken Murchison ([EMAIL PROTECTED]):
> >>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
John Capo wrote:
Quoting Ken Murchison ([EMAIL PROTECTED]):
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
Quoting Ken Murchison ([EMAIL PROTECTED]):
> 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 stip
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"?
John Capo wrote:
Grrr, bad cut-and-paste. Correct patches attached.
Quoting John Capo ([EMAIL PROTECTED]):
These patches handle the messag
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
20 matches
Mail list logo
