Closed Bug 268398 Opened 20 years ago Closed 18 years ago

[IMAP] Subfolders losted on folder rename

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: rcolmegna, Assigned: mscott)

Details

(Keywords: dataloss)

Attachments

(1 file)

Ethereal capture of TB session described in comment #3
26.73 KB, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

If you have an IMAP account and a folder "A" which have subfolder
"A1" and "A2" with some messages if you rename "A" to "A_NEW" subfolders
and mails where losted! 

Reproducible: Always
Steps to Reproduce:
1. create IMAP-account folder "A"
2. create "A1" under "A"
3. create "A2" under "A"
4. put some mails in A1 and A2
5. rename "A" as "A_NEW"

Actual Results:  
A1 and A2 and mails are losted. A is renamed.

Expected Results:  
No mail/subfolder lost.
Severity: blocker → critical
Keywords: dataloss
works for me using 0.9
I had the same prob with TB 1.0 on XP. Using Rclick rename a folder. On 
restart of TB the subfolders were gone. I found them in the TB directories. 
The old folder with the old name intact with subfolders and mail intact and a 
new blank folder. So I copied the contents of the old folder to the new and 
all was OK
I can see and reproduce this behaviour using TB 1.0.6 on both Windows and Linux
(and have therefore tried to change the OS field to "all"). I attach an ethereal
capture of network traffic and could recreate the test account on request. The
IMAP server is imap.strato.de (belonging to a popular German ISP), and the
sequence of events is as follows:

1. Create a superfolder and a subfolder. Thunderbird displays the familiar tree.

2. Rename the superfolder, say to "superfolder 2". Thunderbird changes the name
and continues to show the subfolder under the newly named node in the tree.

3. Click on the subfolder. Thunderbird pops up an error dialog saying (part
until colon translated from German): "the current command was not successful.
The mail server responded: [TRYCREATE] mailbox does not exist." This continues
on every attempt to select the subfolder.

4. Close and restart Thunderbird. The subfolder has disappeared from the tree
display. Running Subscribe reveals that "superfolder 2" does indeed not have a
subfolder. But in the tree shown in the Subscribe dialog, there is a node for
"superfolder" (the old name) in grey, and that has the subfolder below it.
"superfolder" can not be subscribed to (there is no dot to click on), but the
subfolder can - "superfolder" is obvoiusly some kind of ghost folder, it is
always displayed in grey and messages can not moved to it. The situation can now
be corrected through moving or deleting the recovered subfolder (and the old
"superfolder". In the capture, I deleted all folders and compressed the Trash.

Now could it be that this server is simply violating RFC 3501, section 6.3.5?

      If the name has inferior hierarchical names, then the inferior
      hierarchical names MUST also be renamed.  For example, a rename of
      "foo" to "zap" will rename "foo/bar" (assuming "/" is the
      hierarchy delimiter character) to "zap/bar".

Should I just complain to the ISP or should TB also try and find out whether
this behaviour is occuring and then make provisions for it? I don't suspect the
original reporter, being from Italy, is the same ISP. Maybe there are too many
broken servers for TB to assume the rename is carried out as descriebd above? I
vaguely remember the same behaviour with a self-installed Cyrus 2.1 IMAP server
on Debian 3.1, but can't confirm that right now.

If you're not going to check if the whole subtree under "superfolder" needs to
be renamed, at least TB should check whether the server has done the renaming.
(So apparently I'm calling for TB to verify that the server conforms to the
RFC.) As things stand now, TB is showing the tree as it assumes it to be after
the renaming (step 2), not as it really is, and I've seen that cause panic
because people thought they had lost their subfolders.
how about a client side imap protocol log? That's more useful to me.

Substitute IMAP for "protocol" in these instructions:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
I've been sent a personal email asking if I could produce an IMAP log as requested in comment #6. Unfortunately I can't because the error seems to have gone away (tested with TB 1.0.7 as well as 1.5.0.2 under Win2K). I suspect the ISP has got its act together. Sorry.
(In reply to comment #7)
> I've been sent a personal email asking if I could produce an IMAP log as
> requested in comment #6. Unfortunately I can't because the error seems to have
> gone away (tested with TB 1.0.7 as well as 1.5.0.2 under Win2K). I suspect the
> ISP has got its act together. Sorry.
> 

debug file:
----------------------------------------
0[ee1710]: 233f774:k900:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
-4170985[2f2cc50]: ImapThreadMainLoop entering [this=233f774]
-4170985[2f2cc50]: 233f774:k900:NA:ProcessCurrentURL: entering
-4170985[2f2cc50]: 233f774:k900:NA:ProcessCurrentURL:imap://test@k900:143/select%3E|INBOX:  = currentUrl
-4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=141 needmore=0]
-4170985[2f2cc50]: 233f774:k900:NA:CreateNewLineFromSocket: * OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=LOGIN] k900 IMAP4rev1 2004.350mdk at Mon, 5 Jun 2006 17:35:33 +0200 (CEST) -4170985[2f2cc50]: 233f774:k900:NA:SendData: 1 capability -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=179 needmore=0]
-4170985[2f2cc50]: 233f774:k900:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND SASL-IR LOGIN-REFERRALS AUTH=LOGIN -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=27 needmore=0]
-4170985[2f2cc50]: 233f774:k900:NA:CreateNewLineFromSocket: 1 OK CAPABILITY completed -4170985[2f2cc50]: 233f774:k900:NA:SendData: 2 authenticate login -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=20 needmore=0]
-4170985[2f2cc50]: 233f774:k900:NA:CreateNewLineFromSocket: + VXNlciBOYW1lAA== -4170985[2f2cc50]: 233f774:k900:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
-4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=16 needmore=0]
-4170985[2f2cc50]: 233f774:k900:NA:CreateNewLineFromSocket: + UGFzc3dvcmQA -4170985[2f2cc50]: 233f774:k900:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
-4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=173 needmore=0]
-4170985[2f2cc50]: 233f774:k900:NA:CreateNewLineFromSocket: 2 OK [CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User test authenticated -4170985[2f2cc50]: 233f774:k900:A:SendData: 3 namespace -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=126 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * NAMESPACE (("" "/")("#mhinbox" NIL)("#mh/" "/")) (("~" "/")) (("#shared/" "/")("#ftp/" "/")("#news." ".")("#public/" "/")) -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=26 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 3 OK NAMESPACE completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 4 lsub "" "*" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=21 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * LSUB () "/" Trash -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=17 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * LSUB () "/" a -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=18 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * LSUB () "/" a1 -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=18 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * LSUB () "/" a2 -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=17 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * LSUB () "/" c -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=21 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 4 OK LSUB completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 5 lsub "" "#mhinbox*" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=21 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 5 OK LSUB completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 6 lsub "" "#mh/*" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=65 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * NO /home/test/.mh_profile not found, mh format names disabled -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=21 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 6 OK LSUB completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 7 lsub "" "~*" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=21 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 7 OK LSUB completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 8 lsub "" "#shared/*" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=21 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 8 OK LSUB completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 9 lsub "" "#ftp/*" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=21 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 9 OK LSUB completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 10 lsub "" "#news.*" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=22 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 10 OK LSUB completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 11 lsub "" "#public/*" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=22 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 11 OK LSUB completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 12 list "" "INBOX" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=33 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * LIST (\NoInferiors) NIL INBOX -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=22 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 12 OK LIST completed -4170985[2f2cc50]: 233f774:k900:A:SendData: 13 select "INBOX" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=12 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * 0 EXISTS -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=12 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * 0 RECENT -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=51 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * OK [UIDVALIDITY 1149521733] UID validity status -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=37 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * OK [UIDNEXT 1] Predicted next UID -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=52 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=42 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: * OK [PERMANENTFLAGS ()] Permanent flags -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=37 needmore=0]
-4170985[2f2cc50]: 233f774:k900:A:CreateNewLineFromSocket: 13 OK [READ-WRITE] SELECT completed -4170985[2f2cc50]: 233f774:k900:S-INBOX:SendData: 14 IDLE -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=20 needmore=0]
-4170985[2f2cc50]: 233f774:k900:S-INBOX:CreateNewLineFromSocket: + Waiting for DONE -4170985[2f2cc50]: 233f774:k900:S-INBOX:SendData: DONE -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=22 needmore=0]
-4170985[2f2cc50]: 233f774:k900:S-INBOX:CreateNewLineFromSocket: 14 OK IDLE completed -4170985[2f2cc50]: 233f774:k900:S-INBOX:ProcessCurrentURL: entering
-4170985[2f2cc50]: 233f774:k900:S-INBOX:ProcessCurrentURL:imap://test@k900:143/create%3E/a/a1:  = currentUrl
-4170985[2f2cc50]: 233f774:k900:S-INBOX:SendData: 15 create "a/a1" -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=80 needmore=0]
-4170985[2f2cc50]: 233f774:k900:S-INBOX:CreateNewLineFromSocket: 15 NO CREATE failed: Can't create mailbox node /home/test/Mail/a/: File exists -4170985[2f2cc50]: 233f774:k900:S-INBOX:SendData: 16 IDLE -4170985[2f2cc50]: ReadNextLine [stream=2f40a18 nb=20 needmore=0]
-4170985[2f2cc50]: 233f774:k900:S-INBOX:CreateNewLineFromSocket: + Waiting for DONE 0[ee1710]: 233f774:k900:S-INBOX:SendData: DONE 0[ee1710]: ReadNextLine [stream=2f40a18 nb=22 needmore=0]
0[ee1710]: 233f774:k900:S-INBOX:CreateNewLineFromSocket: 16 OK IDLE completed 0[ee1710]: 233f774:k900:S-INBOX:SendData: 17 close 0[ee1710]: ReadNextLine [stream=2f40a18 nb=23 needmore=0]
0[ee1710]: 233f774:k900:S-INBOX:CreateNewLineFromSocket: 17 OK CLOSE completed 0[ee1710]: 233f774:k900:A:SendData: 18 logout 0[ee1710]: ReadNextLine [stream=2f40a18 nb=52 needmore=0]
0[ee1710]: 233f774:k900:A:CreateNewLineFromSocket: * BYE k900 IMAP4rev1 server terminating connection 0[ee1710]: 233f774:k900:NA:TellThreadToDie: close socket connection
-4170985[2f2cc50]: ImapThreadMainLoop leaving [this=233f774]
If I'm reading that log correctly, you had this folder structure:

a
a1
a2
c

and tried to move a1 under a, so you'd have this structure:

a
  a1
a2
c

But the server complained when we tried to create a/a1 because a already exists, which seems like a server bug to me...actually, I'm not sure why we didn't just try to rename a1 as a/a1 - did you do a create or a rename?
I'm trying to create "a1" under "a" (for obtain "a\a1").
OK, your server doesn't like that - perhaps it doesn't support folders that both contain messages and have sub-folders.
I'm using IMAP-Cyrus-srv (the default srv. of a lot of linux distro).

I noticed that some programs use a special character, in name files (ie "\"),
to "simulate" subfolder at namespace-level (so if I need two folder "a\b", on
a linux filesystem, I have two files: "a" and "a\b" [note the "wrong" unix
slash]).

Is there any way do to this via TB?

TIA

yes, you can directly create a new folder in thunderbird with the name "new parent\child" - that will both create "new parent" and then "child" as a sub-folder, and the sub-folder will be able to contain messages; new parent will not. You should also uncheck the box in the advanced imap server settings that says something like "my server supports folders that can contain messages and sub-folders".
WFM/INVALID?
QA Contact: general
YES.  It works correctly on a IMAP Cyrus server.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: