Open Bug 1525033 Opened 6 years ago Updated 5 years ago

mail archived from imap to local folder loses mail

Categories

(Thunderbird :: Folder and Message Lists, defect)

defect
Not set
critical

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: frederic.parrenin, Unassigned)

References

Details

(Keywords: dataloss, Whiteboard: [dupeme])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

I created a local folder named 'archives'
I tried to move some messages from an IMAP folder to this local folder

Actual results:

Nothing, the messages were not moved to the local folder.

Expected results:

The messages should be moved to the local folder.
Note that in one case, the messages were removed from the IMAP folder without being copied to the local folder. So I lost some messages!

Severity: normal → critical
Keywords: dataloss
Summary: Archives local folder does not work → mail archived from imap to local folder loses mail
Whiteboard: [dupeme]

How many messages? usually I see this in support when folks try to move thousands at a single time.

It was indeed a big amount of messages, probably several thousands when I lost messages.
But I cannot move even one message to this local folder called 'archives'.

If you can not move, can you copy?

No, I cannot copy.
Actually, it seems this folder called specifically 'Archives' is treated in a special way in TB.

I have similar problems since some time with one specific mail provider (directbox / MediaBeam).
It seems that mail server is somehow incompatible.
Recently, I moved 8 messages from the imap inbox to a local folder and lost all messages.
In the local folder, 8 empty messages (length 0.2 kbytes) have been created, but
the transaction did not end (rotating cursor for > 30min).
However, the messages have been deleted from the imap folder.
Thunderbird version is 60.5.1 (64-bit) / Linux. The mail server product is unknown.
I cannot reproduce the problem, but the connection to that server appears often slow/unreliable and transactions tend to stuck.

If you do a move from and imap folder to a folder in Local Folders, and tb thinks the copy worked (all messages copied), tb will delete the messages in the source folder. However, if your imap server does not have the MOVE capability or UIDPLUS capability tb will just mark the messages as \deleted. So they are still there unless you compact (imap expunge) the source folder. You can set tb to "just mark as deleted" for the delete action and the missing messages will appear crossed out and you can un-delete them (which just removes the \deleted flag from the message).

But I have never seen this problem.

To be safe when "moving" many message to another folder or to another folder on a different account, it is probably better to just use the copy function and then when the copy finishes, go back and manually delete the the messages in the source folder.

One more tip: When copying to a Local Folder from an imap folder, ensure the source folder is fully sync'd to offline store (right click folder | Synchronize | Download Now) and go offline (*). Then copy the messages to the Local Folder. This will avoid re-fetching all the messages from the server again. See bug 505456.
(*) Actually, the "download now" will cause all message to be re-downloaded, so probably just clicking on source folder is sufficient. Also, if the folder doesn't have offline storage, going offline won't benefit since the messages will still all have to be downloaded before going offline.

For the record, I finally solved my problem with the special 'Archives' folder which was not working in TB.
I went to my profile folder, then 'Mail' and 'Local Folders'.
I deleted three items: a file named 'archives', another file named 'Archives.msf' and a folder named 'Archives'.
After that, the 'Archives' folder was deleted in TB and I could recreate one which was working correctly.
So there is a workaround solution but a better fix would still be appreciated.

You need to log in before you can comment on or make changes to this bug.