Situation: User no longer wishes to keep all e'mail on their system, but wishes to retain ability to look at it. User places all e'mail they desire to archive into a new account. The user then burns that account directory to a CD or other readonly offline storage. At this point, the CD contains a valid folder/tree. The user then changes perf.js to indicate the directory for that account is now on the CD. Expected behavior: The user will be able to browse the messages in the archived account, changes to the account (read status, flagged, sorting) would not carry from one startup to the next.

setting bug status to New

I don't know if Mozilla Foundation is still using the NS keywords, but this enhancement would certainly be useful in a corporate setting - I just archived 3.9 GB (!) of archived email from a user's laptop for LAST YEAR ALONE! I thought I could just burn it onto a DVD for access exactly as the bug suggests, but it didn't work - aparently Mozilla mail requires write-access to the .msf or it won't show anything. Until bug 2920 is fixed, this is a decent way to handle bloated mail folders, and I would hope is a relatively low-effort enhancement.

*** Bug 194635 has been marked as a duplicate of this bug. ***

Changing summary to cover the general case, not just read-only

Hm... on second thoughts... dupe of bug 93094 which covers archiving in an even more general case. *** This bug has been marked as a duplicate of 93094 ***

Wow.. i've been idle from bugzilla for a long time. Aaron: While I agree that the simplified revision to the summary matches the bug you duped this to, it is not exactly what I had in mind. What I was trying to express, and this might be a requisite for the other archive bug, is that is should be possible to open an account directory despite not having write ability to the .msf files. Pop a warning that changes to this account will not be retained, and proceede keeping the .msf changes in memory until a different account is selected.

Aaron, instead of closing this as a dup, since this is a sub-case of the other, they (or you) should mark this bug as a dependency of bug 93094. I would be happy to just have the ability to read RO .msf files since that would at least give us a work-around ability to archive (to say DVD or a RO fileshare), even if they haven't gone through the headache of a GUI, archive process, etc. ad nauseum, which would delay the mimimum capability by weeks if not months.

Could I suggest that Bug 103993 is principally identifying the same problem? I hate to mention that "other" mail client, but it has on the mail side one enormous advantage over TB, it allows the segregation of mail into separate archives. At the moment I have several GB of email which I cannot separate into (for instance) years without the use of a friendly IMAP server. Also related is bug 22689 (unassigned) et al. Th ebottom line is that there is an ever growing collection of bug reports for essentially two things: (1) segregation of data (keeping a subset available, of a collection of separate archives which can be enabled or loaded at will a la Outlook .pts file model) (2) backup/restore functionality which includes profile details and filters. Given the rather large number of almost-dupes on both topics it may be worth for someone to pick them up as next version items to develop. I'd prefer that several miles over Yet Another IM solution ...

(I've been looking for this bug - abbreviations in summaries is not cool) This is a duplicate of bug 37124 - originating in the Netscape days