Closed
Bug 530400
Opened 15 years ago
Closed 15 years ago
TB2.0.0.23: Mailboxes are allowed to grow larger than 4gb in size
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 387502
People
(Reporter: ishikawa, Unassigned)
Details
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: 2.0.0.23 (20090812)
The bug reported here has been fixed in TB3b4 already.
I am reporting the bug for TB2.0.0.23 again and will post a couple of patches
to fix the problem. The patches are backported from TB3 beta code.
Namely, TB2.0.0.23{22 and before as well} silently lets file folder
grow over 4GB size, and once it happens, users can't delete/move/copy
the messages (and may not be able to read them correctly.)
See bug
Bug 387502
Bug 389087
There are basically two problems.
(a)
One is the incorrect file size check, not done properly.
Fixed by the patches for bug 387502.
(b)
There is one underlying problem of using inadequate
system calls to check for file sizes (>=4GB).
Fixed by the patches for bug Bug 389087
I am backporting the patches from TB3 to fix the problem for TB2.0.0.23.
Reproducible: Always
Steps to Reproduce:
1.Create a large folder (near 2GB or whatever)
2.Copy a relatively small file many times to this folder.
3.You will see TB2.0.0.2x silently goes over the
size limit of the folder, 4GB, eventually without complaining
4. You will notice many strange behavior : message headers and bodies not shown correctly, inability to delete a message, etc.
Actual Results:
As noted above.
Expected Results:
TB2 ought to report that copying is aborted because the
mail folder is now too big.
I am going to post the patches for the problems (a) and (b) in subsequent posts.
TB3b4 uses the fixed code now.
I was advised during this summer that the patches for TB2 ought to land
in trunk, i.e., the would-be TB3 beta code, first before
landing the patch for TB2.0.0.2x is considered.
It has been a couple of months, and TB3b4 ships with the proper patches for these problems, and I think it is about time, we should fix TB2 regarding
this problem once for all.
In one of my earlier posts ( Bu 387502 comment # 40)
I said:
--- BEGIN QUOTE ---
============================================+=========
TB 2_0_0_22_RELEASE | 3.0 (comm-central)
---------------------------------------------+---
Proper file size (>=4GB) No. (1) | insufficient, fixed in patch to
check using lstat64, stat64 | nsLocalFileUnix.cpp (#40)
---------------------------------------------+----
Failure to the pass the |
64 bit file size thus | Cleaned up in patch (#40)
obtainedto upper-level Yes.(2) |
routine due to incorrect cast |
in GetFileSize. |
(An argument to LL_UI2L macro) |
---------------------------------------------+----
Check whether the file |
size goes over 4GB Not done.(3) | Now fixed in patch (#39)
while copying | nsLocalMailFolder.cpp
IN ADVANCE |
---------------------------------------------+----
Creating a proper warning message | This requires attention.
for the case where the advance checking |
prohibits copying messages. (5) | { (5)' }
---------------------------------------------+--------
--- END QUOTE
Basically the patches that follow is a backport of the patches to
fix problems (1), (2), and (3) above.
As it turns out, we do NOT need to create a new message [good because
the message is frozen for TB2.]. So (5) above is not necessary.
This file folder going over 4GB is a major cause of data loss for
three of my colleagues who regularly receive large attachments (PDF, PPT)
just before a large exhibition preparation.
I will post the patch for (a) [incorrect file size check] mailnes/local/src/nsLocalMailFolder.cpp
and (b) xpcom/io/nsLocalFileUnix.{cpp,h}
Reporter | ||
Comment 1•15 years ago
|
||
This is a patch for the problem (a) noted above.
Back ported the patch of Bug 387502.
Reporter | ||
Comment 2•15 years ago
|
||
This fixes the problem of not using proper system calls such as stat64 where
applicable.
Backported from the fix in Bug 389087.
Comment 3•15 years ago
|
||
Sorry but the correct way to do this is to attach the back-ported patches to those bugs, request re-review if the changes are significant and then request approval1.8.1.next on the patches.
I do not know if these would be accepted for the TB 2 branch - that would be for the TB 2 branch drivers to decide.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 4•15 years ago
|
||
Dear Mark,
Thank you for pointing out the correct manner to
report the patches for the already fixed bugs in TB3 (and not in
TB2).
Changes are not significant (they are made compatible with TB2 code base.
The newer files are not compilable in TB2).
Anyway, I will re-file the patches.
THX.
You need to log in
before you can comment on or make changes to this bug.
Description
•