Your message was fun, Jeff.
I reasoned this out similarly, thinking along the lines of base-64 used in
MIME. The permissible character set for DOS-platform file names contains at
least 46 characters. The number of different names expressible in 8 base-46
characters is sufficient to have a minuscule collision probability for
archives of any reasonable size. A 100,000 message archive seems two orders
of magnitude too high for MHonArc's basic design; anything that large using
a filesystem as its database needs to be organized hierarchically. That
would add a subdirectory namespace into the quota.
Anyway, sorry I didn't jump in then, but the kind-of-fun question was
implicitly raised: how many bits of randomness do you need for
reproducible URLs in MHonArc? (Hey, it's not every day that real life
questions can be tackled like problem sets!)
Now if we are restricted to ending the filenames with something like
.htm, then there are only about 41 bits of randomness, and then we
run about 1% risk of collision for a puny n=100,000 message archive.
That's pushing it.
Ok, one last note. If we use a real filesystem, with upper and lower
case letters in the filenames, we'd still need 10 characters in the
filename to meet/exceed the acceptable saftey margin (57 bits). So
those lower case letters don't help us much in the region we are
Using MD-5 checksums for filenames is complete overkill statisticly
speaking. They are 128 bits, and would consume 20-odd characters in
the filename. 10 character filenames would do the trick nicely. There
is certainly no need to combine MD-5 and message-ID's from a