Closed Bug 492254 Opened 17 years ago Closed 16 years ago

After compacting, all mail in folder was deleted ("Anywhere Backup" is used for auto-backup)

Categories

(MailNews Core :: Database, defect)

Product:
MailNews Core
Component:
Database
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 498814

People

(Reporter: tryptophan, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.21) Gecko/20090403 SeaMonkey/1.1.16 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.21) Gecko/20090403 SeaMonkey/1.1.16 After receiving the "trash full, unable to delete message" error, I revamped my mail and turned on the auto compact when it will save 100kb feature. Since that point, on two separate occasions, I have been working in a folder that is autocompacting and all the mail in that folder disappears and does not reappear. When I checked the file itself, it showed as 0kb. On the second occasion I was able to restore from back up; the first occasion I was not so lucky. Reproducible: Sometimes Steps to Reproduce: 1.Folder open reading mail 2.autocompact turns on 3.All mail in that folder is deleted Actual Results: Does not happen every time; unpredictable as to when it will happen and I have been reluctant to experiment as I don't want to lose all my mail
Component: General → Database
Product: SeaMonkey → MailNews Core
QA Contact: general → database
Turned off auto compacting and went to manual compacting of folders. Today, after compacting, messages in inbox were gone. Went to back up disk - found inbox file had been deleted. Restored inbox and messages came back After restoring file, tried compacting inbox - inbox compacted without incident
Bug 493065 reports similar phenomenon. Setting dependency for ease of tracking.
Depends on: 493065
Heather, do you run external program which reads Sm's files used for mail folder? (e.g. auto-back software, periodical disk scan by anti-virus software, ...)
I do run external back-up. I'm using Western Digital's "Anywhere Backup" and it is set to back up SMs files.
(In reply to comment #4) > I do run external back-up. There are some problems due to interfere by external software. Bug 494706 (Mail Copy was interfered by auto-backup) See Bug 494706 Comment #32 and Bug 494706 Comment #35. Bug 498814 (If copact Folder is interfered) Bug 498817 (If rebuild Index is interfered) Similar Bug 493065 to yours is opened by opener of Bug 494706, and he uses auto-backup too.
Depends on: 498274
Summary: After compacting, all mail in folder was deleted → After compacting, all mail in folder was deleted ("Anywhere Backup" is used for auto-backup)
Blocks: 493065, 498274
No longer depends on: 493065, 498274
I also experience a similar problem as Bug 494706 where the trash file becomes grossly expanded (4.99 GB) for reasons unrelated to the amount of data being deleted.
(In reply to comment #6) > the trash file becomes grossly expanded (4.99 GB) for reasons unrelated to the amount of data being deleted. If Bug 494706, adding mail data always fails due to file size limit, once 4GB-1 file is created. I think Bug 387502 occurred on you. Once Bug 387502 occurs and excceds 4GB, waning of file size limit will never be issued, so file size continues to increase. (Needless to say, .msf data for greater than 4GB is corrupted.)
Heater, do you have observe again this issue? It seems a dupe of bug #494706 , that is fixed from some months.
Whiteboard: closeme 2010-07-15
I'm still having the deleting file when compacting issue on occasion - it seems to happen if the backup is using the file I'm compacting. The issue of the trash file becoming bloated has not happened in some time (but I've had the trash file disappear and Sea Monkey needs to be shut down before it can be accessed again)
Whiteboard: closeme 2010-07-15
(In reply to comment #10) > I'm still having the deleting file when compacting issue on occasion - it seems > to happen if the backup is using the file I'm compacting. The issue of the > trash file becoming bloated has not happened in some time (but I've had the > trash file disappear and Sea Monkey needs to be shut down before it can be > accessed again) Then is a dupe of bug #498814
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
No longer depends on: 498814
Resolution: --- → DUPLICATE
(In reply to comment #11) > Then is a dupe of bug #498814 If same problem as bug 498814 happened in this bug's case, phenomenon reported by this bug can happen due to problem of bug 498814. However, there is no evidence that phenomenon/problem reported by this bug is same phenomenon/problem which is caused by problem of bug 498814 yet. To (:Aureliano Buendía): What is your evidence that this bug is absolutely same as (==dup of) bug 498814?
(In reply to comment #12) > To (:Aureliano Buendía): > What is your evidence that this bug is absolutely same as (==dup of) bug > 498814? (In reply to comment #10) > I'm still having the deleting file when compacting issue on occasion - it seems > to happen if the backup is using the file I'm compacting.
(In reply to comment #13) (:Aureliano Buendía), I'm asking about *EVIDENCE* instead of your base of your guessing.
(In reply to comment #14) > (In reply to comment #13) > > (:Aureliano Buendía), I'm asking about *EVIDENCE* instead of your base of your > guessing. For me this is an *EVIDENCE*: both issue have same behavior (external application gain access to file while this file is under compaction by TB)... but if you disagree because you think that an evidence must necessarily coincide with a log file or the same error message, you can simply reopen this issue as Unconfirmed, without controversy! Ciao.
(In reply to comment #15) > For me this is an *EVIDENCE*: both issue have same behavior (external > application gain access to file while this file is under compaction by TB)... If same problem as bug 498814 happened in bug opener's original case, phenomenon of this bug can be explained. I'm merely asking you, who duped this bug to bug 498814, about evidence that external application really interfered compaction of folder by Tb in this bug's original case and evidence that it happened in bug opener's case.
No problem ;-) Ciao
You need to log in before you can comment on or make changes to this bug.