> Funny, I've done the same in a different way. > see mail2fs in contrib/nemo. > Also, I have some proposal, skip to the end of the mail and let me know > what you think :) > > In any case, I'd love to see/try your version of upas/fs et al.
/n/sources/contrib/quanstro/src/nupas. cavet emptor. nupas/fs is fully compatable with upas/*. i have been using the mdir format for about 18 months. but i have just recently added the bits to reduce memory footprint. i'm currently spending quite a bit of time on this so details may change. i would appreciate any feedback. > Instead of adapting upas/fs, I use a mail2fs program that uses > upas to convert mail into an "unpacked" form. Each mail is a directory. > A "text" file contains the message text right as you would see it in a mail > reader (including relative paths for attachments). Each attach is decoded > and kept in the mail's directory ready to be copied, printed, etc.; if > possible, > using the same file name reported by the attachment. it's hard denying that this is some allure to this idea and i definately considered it. however, we get quite a bit of three-part email containing the mime parent a 150 byte message and the 400 (with headers) byte replyed-to message. depending on the details of your format, this could require 3 directories + 3 files or 6 blocks of storage for a smaller-than 1 block message. (assuming 8kb blocks.) it also could result in quite a bit more seeking when scanning a number of messages. in addition, this format is not compatable with any of the existing tools. in mdir format, each file looks like a mailbox of exactly one message. in addition, in mdir format each message is self-contained. i can just cp it. finally, a number of email security standards (so-called spf2.0 and s/mime) require the original email. it's not clear to me that one can reconstruct an original mime message from processed parts without leaving some breadcrumbs behind. there's no requirement not to base64-encode us-ascii, for example. - erik
