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)

x86
All
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 387502

People

(Reporter: ishikawa, Unassigned)

Details

Attachments

(2 files)

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}
This is a patch for the problem (a) noted above. Back ported the patch of Bug 387502.
This fixes the problem of not using proper system calls such as stat64 where applicable. Backported from the fix in Bug 389087.
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
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.

Attachment

General

Created:
Updated:
Size: