Richard wrote:
> Thought I would re-explain myself
I'm not sure why, people address both of your concerns adequately with
several solutions all of which work just fine. Instead of reexplaining
yourself take a moment to actually examine the solutions people have offered
to see if they fit your needs.
> Aagain, we lost a very large .mbox file with over 255,000 emails.
> we don't want any kind of (db) box format, just plain text.
> (sql) would be okay.
Furthermore I think that you're not sure what you want. Look at what you
asked for here. You don't want a database solution but you then say a
database, SQL, would be ok. So do you want a database or not? Besides,
strictly speaking, even a slew of individual files inside a file system fails
to meet your needs as a file system is just a very primitive database. It
contains and index (directory entries) to records (files).
I think the core problem here is that you're not quite sure what you want
and are hoping for a silver bullet solution from the list. I don't think
that, given your requirements and contradictory position, that any such answer
will appear to your satisfaction. Furthermore you need to look beyond
particular formats of mail and examine what the true problem was. It isn't
that an mbox file got corrupt. Any file can get corrupt. The problem is that
you didn't have a backup of the file (or files, or SQL database, or any other
solution proposed here) to fall back on. Data integrity is more than just
choosing a file format which might be more (or less) resistant to corruption.
It is having a plan in place prior to such corruption on how to recover from
it. Because no matter what, it will happen eventually.
--
Steve C. Lamb | But who decides what they dream?
PGP Key: 8B6E99C5 | And dream I do...
-------------------------------+---------------------------------------------
signature.asc
Description: OpenPGP digital signature
