dummy line marked E breaks imap

dummy line marked E breaks imap

[Wes Hardaker]

I occasionally accidentally mark a dummy line as expired.  This is
obviously a bad thing to do, but gnus should die on it.  The end
result is that when I try to exit that buffer next I get a internal
error from the imap syncing:

Signaling: (error "Internal error, tag 708 status BAD code nil text Bogus sequence in UID STORE: Syntax error in sequence")
  signal(error ("Internal error, tag 708 status BAD code nil text Bogus sequence in UID STORE: Syntax error in sequence"))
  cerror("Internal error, tag %s status %s code %s text %s" 708 BAD nil "Bogus sequence in UID STORE: Syntax error in sequence")
  apply(cerror "Internal error, tag %s status %s code %s text %s" (708 BAD nil "Bogus sequence in UID STORE: Syntax error in sequence"))
  error("Internal error, tag %s status %s code %s text %s" 708 BAD nil "Bogus sequence in UID STORE: Syntax error in sequence")
  imap-parse-response()
  imap-arrival-filter(#<process "imap" pid 12773 state:run> "708 BAD Bogus sequence in UID STORE: Syntax error in sequence\r\n")
  accept-process-output(#<process "imap" pid 12773 state:run> 0 100)
  imap-wait-for-tag(708 nil)
  imap-send-command-wait("UID STORE -33,33862:33866,33900,33903:33904,33928,34008,34013:34014,34621,34623,34628:34655,34660:34662,34671:34672,34681:34692,34694:34697,34701,34703:34704,34706,34710,34716:34719,34721:34723,34725:34734,34737,34739:34742,34745:34749,34753:34755,34759:34764,34766:34771,34775:34781,34786:34787,34789,34791:34797,34800:34908,34910:34914 +FLAGS (gnus-expire)")
  imap-message-flags-add("-33,33862:33866,33900,33903:33904,33928,34008,34013:34014,34621,34623,34628:34655,34660:34662,34671:34672,34681:34692,34694:34697,34701,34703:34704,34706,34710,34716:34719,34721:34723,34725:34734,34737,34739:34742,34745:34749,34753:34755,34759:34764,34766:34771,34775:34781,34786:34787,34789,34791:34797,34800:34908,34910:34914" "gnus-expire")
  nnimap-request-set-mark("ucd-snmp.mail" (((-33 ... 33900 ... 33928 34008 ... 34621 34623 ... ... ... ... ... 34701 ... 34706 34710 ... ... ... 34737 ... ... ... ... ... ... ... 34789 ... ... ...) add (expire)) ((34742 34746 34802 ... 34839 34866 34868 34871 34884 34889 34893 34906 34908) add (reply))) "hardakers")
  gnus-request-set-mark("nnimap+hardakers:ucd-snmp.mail" (((-33 ... 33900 ... 33928 34008 ... 34621 34623 ... ... ... ... ... 34701 ... 34706 34710 ... ... ... 34737 ... ... ... ... ... ... ... 34789 ... ... ...) add (expire)) ((34742 34746 34802 ... 34839 34866 34868 34871 34884 34889 34893 34906 34908) add (reply))))
  gnus-update-marks()
  gnus-summary-update-info()


-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: dummy line marked E breaks imap

[Simon Josefsson]

Wes Hardaker <wes@hardakers.net> writes:

> I occasionally accidentally mark a dummy line as expired.  This is
> obviously a bad thing to do, but gnus should die on it.  The end
> result is that when I try to exit that buffer next I get a internal
> error from the imap syncing:
>
>   imap-send-command-wait("UID STORE -33,33862:33866,33900,33903:33904,33928,34008,34013:34014,34621,34623,34628:34655,34660:34662,34671:34672,34681:34692,34694:34697,34701,34703:34704,34706,34710,34716:34719,34721:34723,34725:34734,34737,34739:34742,34745:34749,34753:34755,34759:34764,34766:34771,34775:34781,34786:34787,34789,34791:34797,34800:34908,34910:34914 +FLAGS (gnus-expire)")

The problem is the negative UID, I think dummy lines are assigned
negative article numbers.  However, are backends really expected to
handle negative article numbers?  It appears as if there is a bug in
Gnus in that it doesn't remove the negative article number before
invoking the backend.  If not, nnimap should probably just discard
negative article numbers.

Re: dummy line marked E breaks imap

[Wes Hardaker]

>>>>> On Wed, 22 Dec 2004 20:11:50 +0100, Simon Josefsson <jas@extundo.com> said:

Simon> The problem is the negative UID, I think dummy lines are
Simon> assigned negative article numbers.  However, are backends
Simon> really expected to handle negative article numbers?  It appears
Simon> as if there is a bug in Gnus in that it doesn't remove the
Simon> negative article number before invoking the backend.  If not,
Simon> nnimap should probably just discard negative article numbers.

I agree...  I doubt gnus should be handing them down.  It certainly
doesn't seem like adding the complexity to all the backends is worth
the one time you'd have to watch for it above.


-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett