91269 - While moving mail: The current command did not succeed. The mail server responded: Command line too long.

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Roger Martensson]

Cryptic message when downloading my Inbox. 

BuildID: 20001071704
Platform: Windows 2000

Haven't seen this message in previous builds.

Comment 1

[Michael Hendy (Hendikins)]

*** Bug 91270 has been marked as a duplicate of this bug. ***

Comment 2

[Dwayne]

Roger, are you using IMAP or POP?

It sounds like you may have a complex login.  Does this occur every time or just
every now and then?

Is this during an automated download (i.e. "Check for messages every x
minutes"), a manual, or both?

Comment 3

[Roger Martensson]

I'm using IMAP(Uni.Washington IMAP2000).

And yes. It appears everytime I access my Inbox or through the automated mailcheck.

Comment 4

[Roger Martensson]

Did some logging:

This is what my imap log says:
1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: * 6876 FETCH 
(UID 180121 RFC822.SIZE 14731 FLAGS () BODY[HEADER.FIELDS 
("FROM" "TO" "CC" "SUBJECT" "DATE" "MESSAGE-ID" "PRIORITY" "X-
PRIORITY" "REFERENCES" "NEWSGROUPS")] {220}

1704[305c640]: mailosd.ite.mh.se:S-INBOX:STREAM:OPEN Size: 14731: Begin Message 
Download Stream
1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: Date: Mon, 23 
Jul 2001 09:30:26 +0200 (MET DST)

1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: From: Roger 
Mårtensson <[e-mail]>

1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: Message-Id: 
<[e-mail]>

1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: To: 
[e-mail]

1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: Subject: 
Unpack report on blerik

1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: 

1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: )

1704[305c640]: mailosd.ite.mh.se:S-INBOX:STREAM:CLOSE: Normal Message End 
Download Stream
1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: 45 OK UID 
FETCH completed

1704[305c640]: mailosd.ite.mh.se:S-INBOX:SendData: 46 uid copy 
152325,152331:152332,152348,152357,152359,152363,152373,152375:152376,152386,152
389,152392,152394,152399,152404,152406,152408,152410:152412,152414:152418,152422
,152424:152425,152457,152468,152473,152477,152497,152505,152508,152516,152518,15
2524,152536,152539:152540,152551,152553:152555,152557:152558,152560:152561,15256
3,152567,152578,152588,152591,152596,152598,152603,152612,152618:152619,152621,1
52623,152653,152655,152658,152664,152678,15268
1704[305c640]: mailosd.ite.mh.se:S-INBOX:CreateNewLineFromSocket: 46 BAD 
Command line too long


Have fun!

Comment 5

[Roger Martensson]

I haven't seen this messagebox appearing lately.

Maybe is should be closed in favour of:
Bugzilla Bug 92787  
   Filtering takes a long time  

The new bug has nothing to do with this bug, but it appeared when filtering.

But I think that this messagebox might appear again and the code should be 
looked at a bit more closely.

Comment 6

[Hixie (not reading bugmail)]

I get this whenever I try to move my 4000 bugmails out of my IMAP INBOX. As such,
this is a dogfood bug for me -- I can't move my mail out of my inbox.

I just switched to Mozilla Mail after not having touched my inbox much for 2
months, which is why I have 7000+ mails in there.

Pine never used to have a problem moving lots of stuff around, so it's not a
server side bug (or if it is, we should have a way to work around it).

Comment 7

[Mike Waychison]

I'm getting a similar error when reading my imap INBOX.  It seems to happen like
this:

- A query to the server is made for message listing.
- headers are downloaded for INBOX (>2000).
- Messages are filtered and an attempt is made to move them to other mailboxes
on the same imap server.
- While 'Moving Messages to (folder)', i'm prompted with the message:

"The current command did not succeed.  The mail sserver responded: Missing
required argument to UID COPY.Warning prev sibling is not in our list!!!"

The moved messages are still in my inbox on the server, yet don't show up in the
listing in my client.  Next time I attempt to 'get msg' I am stuck having to
download all the headers again.

A work around for this is to clear up the >2000 messages on your own using the
search tool.  The trick is to move <100 (guestimating) messages at a time.  Any
more and the same error occurs.  

My suggestion is to break up all the copy and move commands into smaller chunks
so that they are guaranteed to go through.

Comment 8

[Roger Martensson]

Windows 2k Mozilla 0.9.5+ BuildID 2001110209 

Bug still here..

Have a 10000 mailspooler after vacation so I guess some message moving is 
getting a little bit too much for the IMAP server to cope with..

Comment 9

[Calum Mackay]

Same error "command line too long" when trying to "mark all read" for an INBOX
with 2,000 msgs in it. UoW imaps server.

I think mebbe mozzila should batch things up in this case?

Comment 10

[grylchan]

commercial branch
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020715 

No problems moving 1000 mesgs from one folder to another or
marking 1000 new mesgs as read using a
University of Washington IMAP4rev1 v12.250 mail server.

No problems moving 2665 mesgs from one folder to another
or marking 2665 brand new mesgs as read using
Netscape Messaging 4.15 p4 server 

Not a problem with moving mail, possibly a server issue (imap
iteroperabiity).

reassigng qa to Greg for further investigation and follow up.

Calum what is your buid id and what OS are you using?

Comment 11

[Calum Mackay]

The user who reported it to me is using 1.0, on Solaris/SPARC.

Our IMAP server is UOW:

* OK [CAPABILITY IMAP4 IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] IMAP4rev1
2001.314 at Mon, 22 Jul 2002 17:37:50 +0100 (BST)

Comment 12

[Ken Snider]

This also happens for me when attempting to mark 1079 messages read. I get the
exact same email message.

Running UW IMAP imap-2001a. The server is Red Hat Linux based, if that makes a
difference, though both PINE and Outlook, running in IMAP mode, can mark these
messages read.

Comment 13

[David Juran]

Attachment: captured imap conversation

This is a captuered imap conversation between mozilla 1.3 and UW imapd 2001a.
This probably has something to do with junk control. As you can see on line 259
mozilla tries to store a _LOT_ of message's in the same command. Yes, I do
realize the mailbox is hugem but I just got back from my vacation...

Cut'n'Paste from RFC 2683
3.2.1.5.  Long Command Lines

   A client can wind up building a very long command line in an effort to
   try to be efficient about requesting information from a server.  This
   can typically happen when a client builds a message set from selected
   messages and doesn't recognise that contiguous blocks of messages may
   be group in a range.  Suppose a user selects all 10,000 messages in a
   large mailbox and then unselects message 287.  The client could build
   that message set as "1:286,288:10000", but a client that doesn't
   handle that might try to enumerate each message individually and build
   "1,2,3,4, [and so on] ,9999,10000".	Adding that to the fetch command
   results in a command line that's almost 49,000 octets long, and,
   clearly, one can construct a command line that's even longer.

   A client should limit the length of the command lines it generates to
   approximately 1000 octets (including all quoted strings but not
   including literals).  If the client is unable to group things into
   ranges so that the command line is within that length, it should
   split the request into multiple commands.  The client should use
   literals instead of long quoted strings, in order to keep the command
   length down.

   For its part, a server should allow for a command line of at least
   8000 octets.  This provides plenty of leeway for accepting reasonable
   length commands from clients.  The server should send a BAD response
   to a command that does not end within the server's maximum accepted
   command length.

So clearly mozilla i doing the wrong thing here.

Comment 14

[Ken Snider]

Not just junk - delete a slew of random messages in a folder - the same things
happens.

Looks like Moz should do one of two things:

1. implement the "Should"'s in the RFC and split up the command line
2. Interpret the BAD response for what it is, and try again with a "SHOULD"
RFC-compliant command line.

I would think option 1 is easier to implement on a general scale - split at 8000
octets. The STORE command listed in the example is 96417 octets!

Comment 15

[Illtud Daniel]

We've just hit this problem on a migration of 350 users to mozilla mail.
With increasing mailbox sizes (anybody for a Microsoft Security Warning?)
more and more users will hit this problem. I'm offering to help in any
way I can. (testbed, testing, **** coding).

Comment 16

[Frank Schönheit]

I suppose it's more than the problem described in comment 13. I had a log (not
at hand anymore, unfortunately, but I perhaps can recreate it) from a situation
as described in comment 7:
move, by filter, a lot of mails from one folder to another one, and get a server
response "missing required argument to UID COPY".

The log revealed that the UID COPY command indeed was improperly terminated: The
command string ended in the mid of a message id, and everything after the ids
(including the target for the copy operation) was not present.

So it's not only that Mozilla generates too long commands, sometimes it
generates *incomplete* commands.

I'm always hit by this situation after 3 days of mail abstinence, since I'm
subscribed to some mailing lists with relatively high traffic.

The problem was hard to reproduce on a local mail server with some artificial
mail traffic, since in case of a lot of *generated* (as opposed to real-life)
mails, Mozilla is able to group all the message ids (e.g. "1:2000" instead of
"1,2,...,2000"), so the command string is very short.


Does anybody have any hints about where (what) to look (for) in the code?
Certainly nsNntpProtocol, but any additional explanation of the existing code
would be appreciated ....

Comment 17

[Frank Schönheit]

> Certainly nsNntpProtocol, 
s/nsNntpProtocol/nsImapProtocol/

Comment 18

[Greg Ubben]

Just a comment to be sure you're not observing the 512-character limit
in the NSPR logging module, as described in bug 244478, when diagnosing
this problem.  You'll probably need to use a sniffer log to see what is
really getting passed to the IMAP server.  On Solaris, I use:
    /usr/sbin/snoop -x54 imap.host.name

Comment 19

[David Juran]

The log I submittde in comment# 13 is a sniffer log

Comment 20

[Andrey Belevantsev]

FWIW, I cannot reproduce this anymore with the latest release.  My scenario of triggering a prolem in 1.0.5 was to filter messages in a mail folder of 37,000 messages in total and then to move the resulting 4,000 messages in Trash.

Comment 21

[Wayne Mery (:wsmwk)]

if you've seen this in the past, has the problem gone away?  Or, do you still see it?

2 old bug with similar message: bug 173229, bug 239951

Comment 22

[Frank Schönheit]

Did not see it for a long time. (Might be because I hadn't a three-week vacation for a long time :), it happened to me after the first post-vacation mail-reading, usually.) Using Mozilla 1.7.12.

I'd be fine with closing this, if the others confirm it doesn't happen anymore. Could be reopened later, if necessary.

Comment 23

[Wayne Mery (:wsmwk)]

also Bienvenu indicates problem was fixed, though don't have bug number.
closing WFM