343907 - Mac Thunderbird cannot read mbox files larger than 2GB and cannot write more to a 2GB file

Status: RESOLVED DUPLICATE of bug 462665

(Thunderbird :: General, defect)

Description

[Asa Dotzler [:asa]]

If you attempt to open an mbox file greater than 2GB in Thunderbird on Mac OS X, you get a mostly garbled threadpane and most messages do not display. Also, if open a slightly less than 2GB mbox file and attempt to save more messages, you get a (mostly) incorrect error telling you that your disk is full and you should empty your trash or compact your folders (but at least no dataloss.) 

This only appears on Mac. The greater than 2GB mbox file was created and works fine on Windows. This does not appear to be a problem with copying the file from windows to mac, but rather a problem specific to Mac OS X and 2+ GB files. 

Tested on OS X 10.4.x on Intel with the 1.5.0.x universal binary

Comment 1

[joe higton]

We're having this problem with our mac operators (Tiger - Thunderbird 1.5).

I got them to compact the folder which temporarily alleviated the problem, and also set up a rule to archive the mail off.

Comment 2

[JT Moree]

We have a similar problem on windows.  Using mozilla and seamonkey.  When a INBOX or Sent gets to 2G in size it stops working.  We have to move the files around and tell the user that they can only read from it but cannot add or delete.  Some are located on local drives and others are on a samba share.

Comment 3

[David :Bienvenu]

yes, this is fixed in newer versions, I believe.

Comment 4

[JT Moree]

We're using Seamonkey 1.1.0 and 1.1.1.  I haven't seen it with 1.1.1 yet but I'll try to do some tests.  What newer versions do you think this is fixed in?  and what is fixed?  Is the 2G limit removed?  Is the program smarter about dealing with the 2G limit?  Does it allow one to recover when this limit is hit?

Comment 5

[joe higton]

(In reply to comment #3)
> yes, this is fixed in newer versions, I believe.
 
Do you know which version (in terms thunderbird releases)? 

Comment 6

[David :Bienvenu]

2.0

Comment 7

[guanxi]

I've definitely seen this problem in 2.x, up to 2.0.0.6 at least, on Windows. We have one incident documented from last week on 2.0.0.6.

We've supported many installations of Moz Suite and TB, on many versions of Windows for years. We've seen the problem many times and I've never seen a folder larger than 2GB.

(If this is the problem as on OS X, we should update the summary & platform; if not, let me know and I'll open a Windows bug.)

Related bugs: bug 207400, bug 378142

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #7)
> I've definitely seen this problem in 2.x, up to 2.0.0.6 at least, on Windows.
> We have one incident documented from last week on 2.0.0.6.

Bug 428147 has reported following phenomenon when (A) mail folder file size>2GB, (B) OS : 64 bit Fedora, (C) MS Win's partition, which is mounted with ntfs-3g.
 (1) After Rebuild Index by Tb 2 on Linux,
     - Negative value in "Order Received" column(offset) for mail of offset>2GB
     - Other message list pane display(such as subject) seems to be correct
     - Wrong data for mail body when offset>2GB
 (2) After new mail download when mail folder file size>2GB,
     - New mail data is appended to mail folder file
     - ZERO in "Order Received" column(offset) for the new mail
 (3) It seems "no problem when MS Win", because same mail folder file is shared
     by Tb on MS Win and Tb on Linux when Bug 428147 reporter's case.
Above is very similar phenomenon to one in comment #0 on Mac OS X, except some diferrences.

Root cause on Mac OS X & Linux seems to be Bug 362244.
> Bug 362244 Support large files (>= 2GB) on all platforms with large file support
When MS Win32, Bug 362244 doesn't seem to have relation(MS Win is not listed in it).

To guanxi:

Comment #0 says :
> The greater than 2GB mbox file was created and works fine on Windows.
What phenomenon/problem on Windows? Same one as comment #0?

Comment 9

[Hiroyuki Ikezoe (:hiro)]

(In reply to comment #8)
> Root cause on Mac OS X & Linux seems to be Bug 362244.
> > Bug 362244 Support large files (>= 2GB) on all platforms with large file support
> When MS Win32, Bug 362244 doesn't seem to have relation(MS Win is not listed in
> it).

I think the issue occurs on Windows too. But the BUG you mentioned is just a NSPR BUG. XPCOM(obsolete) has also 2GB limit issues.
See Bug 450359.

Comment 10

[Jim Michaels]

yes, the windows version has this problem too.
actually, the filesize limit is 2^32-1=2GiB-1=2147483647 I think, just like the firefox browser filesize limitation.  somebody used a 32-bit int or a long for the filesize or something like that instead of a long long (gcc) or a __int64 (MINGW, borland, MSVC++).

however, on MinGW compiler which is a gcc variant, it does not natively support __int64 so you must do something like
/*detect MinGW compiler and if it is*/
#if defined(__MINGW32__)
#include <basetsd.h> /* defines __int64.  not needed for borland, MSVC++ */
typedef __int64 qlong;
/* now define a printf format string we can use */
#define QLPRINTF "%I64d"
#elif defined(__BORLANDC__)||defined(_MSC_VER)
typedef __int64 qlong;
/* now define a printf format string we can use */
#define QLPRINTF "%I64d"
#elif defined(LINUX)
typedef long long qlong;
/* now define a printf format string we can use */
#define QLPRINTF "%lld"
#elif defined(__DJGPP__)
typedef long long qlong;
/* now define a printf format string we can use */
#define QLPRINTF "%lld"
#endif


your mileage will vary for your distribution/build of linux depending on what -D options you have on gcc/g++, it may not use LINUX #define.  check your build scripts and makefiles.
Jim Michaels

Comment 11

[Makoto Kato [:m_kato]]

Local folder limit is 4GB on Thunderbird 3.1 by bug 538512.
Do dup of bug 462665 for over 4GB folder support.