Closed
Bug 239951
Opened 20 years ago
Closed 10 years ago
Source folder locked (busy?) after failed move with the error The current command did not succeed. The mail server responded command too long. (timeout)
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 263821
People
(Reporter: asa, Unassigned)
References
Details
Not positive I got the error message correct but after trying to move about 2500 messages from IMAP to local folders, I got this error message and then moving from that folder no longer works. Steps to reproduce: 1. Move about 2500 messages from Inbox on IMAP to a local folder. 2. Move fails with error. 3. Dismiss error, select a message in Inbox, and attempt to move it anywhere. Results: No messages can be moved from Inbox. Expected: Folder not be locked after failed move.
Comment 1•20 years ago
|
||
Ah, move to a local folder - I didn't realize that part. That means the fetch command is too long. I can fix that, I think...however, the lock part is weird. I would expect the destination folder to get locked, not the source, since it's the destination that gets locked when we do a move/copy. Can you read messages in the inbox after this happens?
Updated•20 years ago
|
Product: MailNews → Core
Comment 2•16 years ago
|
||
David, would this have been fixed elsewhere?
QA Contact: grylchan → networking.imap
Assignee | ||
Updated•15 years ago
|
Product: Core → MailNews Core
Comment 3•15 years ago
|
||
was this a drag operation, or move by keyboard?
Updated•12 years ago
|
Assignee: dbienvenu → nobody
Comment 4•11 years ago
|
||
bug 406929 also relates to timeout
Severity: normal → major
Summary: folder locked (busy?) after failed move with the error The current command did not succeed. The mail server responded command too long → Source folder locked (busy?) after failed move with the error The current command did not succeed. The mail server responded command too long. (timeout)
Comment 5•10 years ago
|
||
Given the staleness of this bug, finding no support requests complaining about this, and no open bugs about command too long except bug 263821 ... duping to bug 263821, where user reports on 2007-05-02 seeing this in version 2 time line FTR: - fixed 2004-04-12 - Bug 238680 - On a heavily filtered inbox, "mark as read" generates needlessly long IMAP commands // Bug 238680 comment 5 "This fixes the store command to both coalesce ranges using the flag state, and to limit store command lines to 950 bytes. Along the way, I found a bug in the code that limits the command line length in that it didn't correctly say how many entries had been handled - this wasn't a problem for fetch headers, usually, because headers tend to get fetched in ranges anyway, but it could be an issue for downloading for offline use" - Bienvenu 2004-04-08 bug 239951 comment 1 - fixed 2004-03-04 - Bug 220256 - downloading imap mails when going offline fails with large numbers of non-contiguous message - (bug 217518) David :Bienvenu 2003-08-27 19:38:16 PDT I fixed this for header fetching. I haven't done it for store yet.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•