Huge mailbox split?
in [Shell]
|
From: Tuxedo on 16 Jun 2010 08:53 John Kelly wrote: > Low level tools like dd help focus on the real problem. dd is good :-) > What? You said you rescued an old drive. So if the .msf file no longer > exists, how can you know it had a .msf file? I'm not entirely sure, I only presume the mbox had a corresponding .msf index when it was working, because the huge mailbox was working on the original system. As far as I understand and have also tested, if an mbox without .msf file is placed in a relevant Mozilla T-Bird folder, the .msf index will be created once firing up T-Bird. If the index does not exist, the parsing of the mbox takes longer, which is mainly noticeable when initally created against a fairly large mbox. By that I also understand that the mail application reads the index rather than the mbox itself when used and only when clicking on a particular message listing, the mail application returns the relevant message part of the mbox to display to the user by the GUI. Transferring other less than a gigabyte sized mail folders worked fine and the .msf indexes were created as expected. Whatever happened to the original .msf index for the huge mbox, I do not know for sure. I did not personally rescue the data, so maybe the file was lost or perhaps it did in fact not even exist. The problem I think I have is while the mail application attempts to create the index on a new set up the file has grown so huge that the process of creating this index terminates because the file is too large for the system or application to read in at once. Anyway, I guess this is the problem, but there could also be something else wrong with the file. It surely is not a plain text format mbox. > I'm beginning to wonder if this thread is a practical joke. Not at all, though I can think of more entertaining topics than trying to recover the contents of a 2.8GB Windows Mozilla T-Bird mbox :-) Tuxedo
From: John Kelly on 16 Jun 2010 09:06 On Wed, 16 Jun 2010 14:53:05 +0200, Tuxedo <tuxedo(a)mailinator.com> wrote: > It surely is not a plain text format mbox. Must be in Mozilla compacted format. But if you can't get any Mozilla to read it, I don't what more you can do. -- Web mail, POP3, and SMTP http://www.beewyz.com/freeaccounts.php
From: Tuxedo on 16 Jun 2010 09:34 John Kelly wrote: [...] > Must be in Mozilla compacted format. But if you can't get any Mozilla > to read it, I don't what more you can do. What actually happens after moving the file into A relevant Mozilla folder and after firing up T-Bird, the progress bar in the bottom right of the mail application begins to move and the status bar indicates the following: Building summary file for MyBigCrapBox... Depermining which messages to index... While the progress bar continues in hopeful anticipation until it all ends in a small tragedy maybe about a minute later, choking on the big file. No related .msf created. No message shown in the folder. I'm trying this with on a fast windows box with 4GB Ram. So it may be similar to as if trying to read in the full file with formail on Linux until running out of memory. Mozilla Compact sounds familiar! I guess nobody here happes to know an uncompress command for that exotic compression format :-). After all, it should be open source... Tuxedo
From: John Kelly on 16 Jun 2010 09:48 On Wed, 16 Jun 2010 15:34:30 +0200, Tuxedo <tuxedo(a)mailinator.com> wrote: >Mozilla Compact sounds familiar! I guess nobody here happes to know an >uncompress command for that exotic compression format :-). After all, it >should be open source... It is. You could read the Mozilla source and try to hack out your own solution. But as for shell related solutions, I think we have reached the point of diminishing returns. -- Web mail, POP3, and SMTP http://www.beewyz.com/freeaccounts.php
From: Janis Papanagnou on 16 Jun 2010 09:53
John Kelly schrieb: > On Wed, 16 Jun 2010 02:07:09 +0200, Janis Papanagnou > <janis_papanagnou(a)hotmail.com> wrote: > >> To prevent a message body line starting with "From [...]" you can defined >> the pattern more accurate, instead of /^From / specify (for example)... >> >> /^From - [A-Z][a-z][a-z] [A-Z][a-z][a-z] .* [0-9][0-9][0-9][0-9]$/ {...} >> >> or perhaps just >> >> NF==7 && /^From / {...} > > I wonder how mail programs cope with that. The extra test is good, but > not foolproof. No test can be foolproof, unless "^From " in the body is > escaped (mangled) when stored. > > > Certainly not foolproof. You've read the "perhaps just", I suppose? Just to be sure that you understand what I suggested; in the first pattern the /.*/ was meant as an abbreviation (nontheless functional effective) for a complete pattern, as defined in the /^From / line. I abbreviated it to fit on a line, for posting purpose. Generally; how would a regexp be able to distinguish in a primitive mbox data format between the From line and a data line starting with /From/ and being preceeded with an empty line and followed by /Tags:/ lines? We both know that. Janis |