User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 I have ~450 IMAP folders and I am now trying to organize them into a hierarchy structure. IMAP server in this case is Dovecot 1.1.13. To explain the bug, lets say there are folders A, B, C, D, E and F. I can successfully move B and C into folder A. After that, attempts to move any other folders into A fail silently - nothing happens, not even an error dialog. Terminating Thunderbird and restarting it will allow me to move another two folders into A, like D and E. Attempts to move folder F into A will again fail silently until I restart. Reproducible: Always Steps to Reproduce: 1. Create IMAP folders named "A", "B", "C", "D", "E", "F". 2. Move folders "B" and "C" into "A". 3. Try to move folder "D" into "A". It should silently fail to move. 4. Exit Thunderbird, and relaunch it. 5. Move folders "D" and "E" into "A". 6. Attempt to move folder "F" into "A". It should silently fail. ... this can be repeated over and over with other folders. Actual Results: Exactly what was described. Expected Results: Any number of folders should be movable into another folder in the same session. Completely terminating Thunderbird and restarting it should NOT need to be done.

Dossy can you create an imap log as described in https://wiki.mozilla.org/MailNews:Logging for imap and attach it to this bug please ?

imap:5 log reproducing the steps documented in this bug

Ludovic: Thanks for the pointer to the imap log instructions. I've created such a log and have attached it. After moving "B" and "C" into "A", when trying to drag "D" into "A", no new log entries are created. I tried dragging several times, but it wasn't resulting in any new log entries, so I ended my test and quit Thunderbird.

From the log it seems you log out of the server - but I'm no expert here.

Yes, I quit and logged out after trying to drag folder "D" into "A" several times. You changed this bug to "Networking: IMAP" but as you can see from the logs, the UI frontend doesn't even trigger an IMAP request in response to the drag-and-drop action. It feels more like a bug in the folderPane tree's listener. Still, perhaps the IMAP folks are more familiar with the code involved, anyhow. Thanks for looking into this!

Dossy, can you try a 3.03pre build? I fixed some issues like this, though I think it was before 3.0b2 - as you say, this isn't a problem in the imap protocol code, most likely, but rather a problem cleaning up the move/copy state such that we know we're no longer copying a folder into the target folder - we don't allow overlapping copies into the same folder.

I'm able to reproduce this issue in a Shredder build on OSX as of yesterday.

(In reply to comment #6) > Dossy, can you try a 3.03pre build? I fixed some issues like this, though I > think it was before 3.0b2 this is most alike bug 448550, where Dossy commented. But I not sure we had something of that type fixed into b2. perhaps you're thinkg of things like bug 467994 > but rather a problem cleaning up the move/copy > state such that we know we're no longer copying a folder into the target folder > - we don't allow overlapping copies into the same folder. fails 20090604 build on XP. move 2 folders. works. move 1 more. fails. Within the same account. if move to another account, no problems. I have an imap log if needed. only thing in console... Error: Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [mozIStorageStatement.bindInt64Parameter] Source file: file:///C:/Program%20Files/mozilla.org/tb%203.0b%20090604/modules/gloda/datastore.js Line: 2220

This should fix the problem but it doesn't handle the failure case. I think to handle that I do need to use InitCopyState + OnStopRunningUrl solution, since that gets called for both success and failure...I attach this patch just in case the other solution turns out to be hard...

This uses a copy state and OnStopRunningUrl like the other move/copy operations. So it's a slightly bigger change, but more consistent with the other move/copy operations. This is certainly worthy of a test case - I'll probably extend test_imapFolderCopy.js to include some intra server folder moves.

David: Nicely done. I have verified that patch 382597 makes the test case I described above pass - I am now able to move folders B, C, D and E into A during the same session.

(In reply to comment #10) > This is certainly worthy of a test case - I'll probably extend > test_imapFolderCopy.js to include some intra server folder moves. Setting the flag so we don't forget.

fakeserver doesn't seem to support rename (or it's broken in this case), but this test case *should* work once I make some more fakeserver fixes. Here's the error: 2009-05-11 15:45:23.497000 UTC - 4376[2d44a88]: 2ddfb28:localhost:A:SendData: 23 rename "INBOX/empty 2" "INBOX/empty 1/empty 2" 2009-05-11 15:45:23.500000 UTC - 4376[2d44a88]: ReadNextLine [stream=2d815a0 nb=31 needmore=0] 2009-05-11 15:45:23.500000 UTC - 4376[2d44a88]: 2ddfb28:localhost:A:CreateNewLineFromSocket: 23 BAD Internal server fault.

Comment on attachment 382597 [details] [diff] [review] proposed fix > rv = imapService->MoveFolder(m_thread, > srcFolder, > this, > urlListener, I'd just pass "this" again for urlListener rather than badly QIing ;-)

carrying forward sr, re-requesting r=, while I go bang my head on fakeserver...

this requires the fix for bug 497959, which is awaiting review.

but the main patch that actually fixes the bug can land by itself...

Comment on attachment 382861 [details] [diff] [review] fix addressing Neil's comments I am seeing various gloda assertions such as: ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'[JavaScript Error: "srcURI is not defined" {file: "file:///Users/moztest/comm/main/tb/mozilla/dist/ShredderDebug.app/Contents/MacOS/modules/gloda/indexer.js" line: 2176}]' when calling method: [nsIMsgFolderListener::folderMoveCopyCompleted]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "<unknown>" data: yes] ************************************************************ and ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [mozIStorageStatement.bindInt64Parameter]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: file:///Users/moztest/comm/main/tb/mozilla/dist/ShredderDebug.app/Contents/MacOS/modules/gloda/datastore.js :: gloda_ds_markMessagesDeletedByFolderID :: line 2220" data: no] ************************************************************ Assuming they aren't a direct consequence of this patch r=Standard8. Could you file a follow-up bug if they aren't to do with this?

fix checked in - I'll file a follow-on bug for gloda. I don't remember seeing those myself, but gloda is a little rough around the edges in the area of folder operations...

backed out test case since the imap fake server changes are required and can't land until jcranmer reviews those changes...reverting in-testsuite+

Bug 498914 filed for gloda errors.

the test was landed a while ago.