697567 - Export Mail failure without notification

Status: RESOLVED DUPLICATE of bug 675448

(MailNews Core :: Backend, defect)

Description

[a9026237]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

I selected all Mails (over 1000) in one folder and made a right click and chose "Save as..." (Speichern unter...).  Then I selected a folder.


Actual results:

Mails were exported but not all. About 20 Mails were missing.
I then selected another folder which has a shorter name. Now only 3 Mails are missing. 
Longest filename has 245 characters. Thunderbird seems to create name for the exported mails in the following scheme:
Subject - sender - date time.eml
I have Mails with long subject and long sender adress in this folder. 
It seems to me that thunderbird has a problem with filenames > 256 chars. 
According to this http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath longer filenames are possible (Windows Explorer can deal with much larger filenames). So solution is either to use Unicode Version of windows API or changing the naming scheme like cutting the subject after 10-20 chars. 
Please note that this problem with too long filenames also exists with import when you drag the mails to an empty folder. If you have renamed the base folder containing the mails so that the complete path is now longer than about 256 chars then Thunderbird doesn't permit you anymore to drop these files into its windows and thus prevents importing.

IMPORTANT: Thunderbird does not inform about the fact, that some mails could not be exportet. You'll notice it only by manually comparing the number of mails in the folder in Thunderbird and the number of files in the folder in the file system.


Expected results:

a) Thunderbird should have used the Windows API Unicode version so that the long filenames are no longer a problem, this must be done also for the import via drag and drop!!!
b) Thunderbird should shorten the subject so there is no problem anymore with too long filenames.

Comment 1

[a9026237]

Priority is Critical because exportet mails are dropped silently when this bug occurs.

Comment 2

[Hashem Masoud]

(In reply to a9026237 from comment #1)
Agreed, if it fails to save a file it should report it. Maybe error console shows that but still the error should be presented to the user clearly. 

See bug 557779 comment #1. Also, I suggest you use this addon: https://addons.mozilla.org/en-US/thunderbird/addon/importexporttools

Comment 3

[mark van tilburg]

Bug report for version: 24.2.0

Does not seem to be connected to the filename length. I can save them like 20 at a time and it works ok for the entire folder.

But the messages that are saved look very similar by subject, who and the datetime as it's logging from a system.

If the file already exists it might overwrite it without giving a notice to the user that there was already a file with the given name. This could reproduced by sending a couple of e-mails within one minute as they all have the same name. e.g. this:
1) [e-mail] RE: X 9:52
2) [e-mail] RE: X 9:52
3) [e-mail] RE: X 9:52

Where this are 3 messages and not 2 messages as the saving either overwrites the first or doesn't save the 3rd.

Comment 4

[mark van tilburg]

The path length of 255 seems to be the issue for saving messages. 

But thunderbird does not show an error that saving of any message failed.

Is more information needed?

Comment 5

[mark van tilburg]

Attachment: thunderbird_save_as_error.png

When saving multiple messages and the file already exists it gets a number behind the filename. However this increasing number is not overwritten and it generates a numbering scheme like:

-2
-2-3
-2-3-4
-2-3-4-5

That should be:
-2
-3
-4
-5

Comment 6

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

(In reply to mark van tilburg from comment #5)
> Created attachment 8386060 [details]
> thunderbird_save_as_error.png
> 
> When saving multiple messages and the file already exists it gets a number
> behind the filename. However this increasing number is not overwritten and
> it generates a numbering scheme like:
> 
> -2
> -2-3
> -2-3-4
> -2-3-4-5
> 
> That should be:
> -2
> -3
> -4
> -5
This has been fixed in bug 1207364.

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This issue has been fixed earlier this year in bug 675448. The fix is contained in Thunderbird 38.0