97830 - Ability to browse e'mail despite RO (read only) .msf files

Status: RESOLVED DUPLICATE of bug 37124

(MailNews Core :: Backend, enhancement)

Description

[Quinn Yost (mythdraug)]

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.

Comment 1

[Asa Dotzler [:asa]]

setting bug status to New

Comment 2

[Michael Baffoni]

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.

Comment 3

[Aaron Lawrence]

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

Comment 4

[Aaron Lawrence]

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

Comment 5

[Aaron Lawrence]

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 ***

Comment 6

[Quinn Yost (mythdraug)]

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.

Comment 7

[Michael Baffoni]

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.

Comment 8

[Peets]

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 ...

Comment 9

[Wayne Mery (:wsmwk)]

(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