Cleaning up M2
Francis Johnson
I have an Opera installation that goes back to O6 (or maybe even O4 or so,
can't remember). I have used the mail feature since whenever it was first
implemented; for mails, usenet and RSS. I regularly (manually) delete all
news and RSS, but never delete mail except for mailing lists, spam or
other junk (forum notifications etc.). The whole Opera installation was
always upgraded through every Opera version smoothly, no problems that I
can remember.
At the moment, after clearing Trash, the Mail/ folder has 867 MB in 23.231
files, 5.447 folders. Opera's "Received" view knows about 28.206 items.
There was the occasional hickup though, a HDD failure here or there, etc.,
the usual stuff. While restoring the last daily backup of Mail/ today
(there was a power outage, and omailbase.dat as well as indexer/message_id
were ~ 1 KB - so, and no journal files existed => total loss), I browsed
the Mail/ folder a bit. Here are some things I noticed.
- Can I delete all *.tmp files below Mail/ when Opera is not running?
- mailbase.dat too?
- Can the contents of Mail/cache be deleted when Opera is not running? It
as 725 files, mostly size 0.
- Can the folder Mail/storage (not Mail/store) and the .mbs files it
contains be deleted? I guess it's from an older version.
- I seem to have developed account creep. While accounts.ini contains
exactly what it is supposed to (5 accounts) In Mail/store, I have about 70
account folders. Most of these contain one single directory+file, all of
them named Mail/store/account*/2007/05/19/*.mbs. All those .mbs files
contain some dummy header ("From ", "X-Opera-Status: ..." and "Date: Sat,
19 May 2007..."). Obviously, something happened on that day which created
all those accounts. Can I simply delete all those folders (i.e., the
accountXXX folders)? Do I have to look somewhere else as well? Will Opera
notice gracefully and clean its index etc.? Or is it advisable to leave
that issue alone?
Those seem to be the things that can be fixed manually. How about the
indexer, lexicon and omailbase.dat files? Assuming some things are
sub-optimal in there as well, is there a hassle-free way to clean up as
well without losing substantial data or investing lots of manual work? Or
is that usually not necessary (especially since they have just been
rebuilt in the recent M2 version change, and are thus probably rather
clean)?
More general questions, just for completeness sake:
- In the "real" accounts (i.e., not the junk accounts mentioned above),
there are lots of folders on the "day" level (e.g.
Mail/store/accountXXX/2007/04/17) that contain no .mbs files at all. I
assume that is the news account where I regularly delete all mails. Can I
delete all Mail/store sub-folders that are completely empty?
- What happens if I delete some .mbs file. Obviously the items in it are
gone. But will the indexer/lexicon/omailbase.dat be upgraded gracefully
(whenever that .mbs would be accessed and is not found anymore), or is
that not supported?
Thanks in advance for any answers!
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
David W. Hodgins
> - I seem to have developed account creep. While accounts.ini contains
See http://groups.google.com/group/opera.mail+news/msg/44d5018b21f60909?
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Rijk van Geijtenbeek
> I have an Opera installation that goes back to O6 (or maybe even O4 or
> so, can't remember). I have used the mail feature since whenever it was
> first implemented; for mails, usenet and RSS. I regularly (manually)
> delete all news and RSS, but never delete mail except for mailing lists,
> spam or other junk (forum notifications etc.). The whole Opera
> installation was always upgraded through every Opera version smoothly,
> no problems that I can remember.
>
> At the moment, after clearing Trash, the Mail/ folder has 867 MB in
> 23.231 files, 5.447 folders. Opera's "Received" view knows about 28.206
> items.
>
> There was the occasional hickup though, a HDD failure here or there,
> etc., the usual stuff. While restoring the last daily backup of Mail/
> today (there was a power outage, and omailbase.dat as well as
> indexer/message_id were ~ 1 KB - so, and no journal files existed =>
> total loss), I browsed the Mail/ folder a bit. Here are some things I
> noticed.
>
> - Can I delete all *.tmp files below Mail/ when Opera is not running?
I think so, not sure what those file are though.
> - mailbase.dat too?
Yes, omailbase.dat is now the main database, mailbase.dat is not used anymore in 9.5+.
> - Can the contents of Mail/cache be deleted when Opera is not running?
> It as 725 files, mostly size 0.
> - Can the folder Mail/storage (not Mail/store) and the .mbs files it
> contains be deleted? I guess it's from an older version.
Yes, those are folders from earlier versions of Opera Mail (7.0-7.2). If your upgrade to 7.5 went OK, you'll have no need for them, all the data will have been moved to the newer storage structures.
> - I seem to have developed account creep. While accounts.ini contains
> exactly what it is supposed to (5 accounts) In Mail/store, I have about
> 70 account folders. Most of these contain one single directory+file, all
> of them named Mail/store/account*/2007/05/19/*.mbs. All those .mbs files
> contain some dummy header ("From ", "X-Opera-Status: ..." and "Date:
> Sat, 19 May 2007..."). Obviously, something happened on that day which
> created all those accounts. Can I simply delete all those folders (i.e.,
> the accountXXX folders)? Do I have to look somewhere else as well? Will
> Opera notice gracefully and clean its index etc.? Or is it advisable to
> leave that issue alone?
Deleting folder branches in Mail/store is OK if you don't see any mbs files there with messages you actually want to keep. I don't know if Opera will clean up the database when it finds those files missing, but it doesn't do harm either way.
> Those seem to be the things that can be fixed manually. How about the
> indexer, lexicon and omailbase.dat files? Assuming some things are
> sub-optimal in there as well, is there a hassle-free way to clean up as
> well without losing substantial data or investing lots of manual work?
No.
> Or is that usually not necessary (especially since they have just been
> rebuilt in the recent M2 version change, and are thus probably rather
> clean)?
That's correct. The mail system in 9.5 is more robust.
> More general questions, just for completeness sake:
>
> - In the "real" accounts (i.e., not the junk accounts mentioned above),
> there are lots of folders on the "day" level (e.g.
> Mail/store/accountXXX/2007/04/17) that contain no .mbs files at all. I
> assume that is the news account where I regularly delete all mails. Can
> I delete all Mail/store sub-folders that are completely empty?
Yes. Opera 9.5+ is much better in doing that for you automatically, but it will not try to clean up empty folders left by previous versions of Opera.
> - What happens if I delete some .mbs file. Obviously the items in it are
> gone. But will the indexer/lexicon/omailbase.dat be upgraded gracefully
> (whenever that .mbs would be accessed and is not found anymore), or is
> that not supported?
Good question, I don't know :)
> Thanks in advance for any answers!
--
Rijk van Geijtenbeek
Opera Software ASA, Documentation & QA
Tweak: http://my.opera.com/Rijk/blog/
"The most common way to get usability wrong is to listen to what users
say rather than actually watching what they do." - J.Nielsen
Francis Johnson
<dwho...@nomail.afraid.org> wrote:
>> - I seem to have developed account creep. While accounts.ini contains
>
> See http://groups.google.com/group/opera.mail+news/msg/44d5018b21f60909?
Thanks.
I think I played around with mbs2mbx some months ago. I am not yet ready
to export/re-import all; everything is running too smooth for that. Right
now I'm just looking at some spring-cleaning. I'm pretty happy that Opera
uses the .mbs format internally, so if disaster really strikes there will
always be a way to get at the old data (and I do have daily backups ;) ).