> Given that the current mbox file format doesn't scale well to > tens of thousands of emails, I'm not worried about the fact that > the file system doesn't either.
The standard hack (did MH ever pick this up?) is to split the directory, e.g., message 32456 is stored in 32/456 or 3/2/456. The huge storage/locality win for separating out large attachments if you have venti-like storage (or want to cache virus-scan results) may well justify tearing the file apart on nextpart boundaries--my only concern is that the process be 100% reversible by upas when you ask. Heck, it could be as simple as "each message is 1 directory, containing chunks stored one per file, named by integers, and the original message is formed by cat'ing the chunks in numerical order". That would let the storing agent decide whether the nextpart boundary foo belongs in the same chunk as the bits or in its own micro-chunk. Dave Eckhardt P.S. At present upas does the >From thing, which isn't reversible.
