On Wed, Dec 10, 2003 at 11:25:06PM -0600, Chad Walstrom wrote:
] Not an entirely bad idea. ;-) I know it's been mentioned here before.
] There are some big logistical issues with this, however. MH format uses
] the filesystem not only as a repository for email, but as a sorting
] mechanism as well. Emails are actually renamed in sequence by the
] 'sort' program. With Maildir format, your mail client must cache an
] index of references to the actual emails on the filesystem. Both
] approaches have their strengths and weaknesses.
MailDir also makes user of nameing convention for sorting.
tokyo# ll new
-rw------- 1 v-worst v-worst 5539 Dec 10 19:18 1071112710.18167_0.tokyo
-rw------- 1 v-worst v-worst 8822 Dec 10 20:03 1071115425.18279_0.tokyo
Things get numbered as they come in. Mail messages that come in at the
exact same time get the _0 incremented.
tokyo# ll cur
-rw------- 1 v-worst v-worst 408 Jun 22 16:17 1056323803.664_1.tokyo:2,Sc
The additional issue is that MailDir changes the end of the filename to
represent certain flags.
The big issue is that the equivalent of the unseen seqence is done
via "new" versus "cur" directories for the messages.
There are probably several solutions to the renumbering issue. The
trick is keeping things in sync with other mechanisms that might be
using the store.
tokyo# ll .Trash
-rw------- 1 v-worst v-worst 22 Jun 4 2003 .customflags
-rw------- 1 v-worst v-worst 1608 Jun 24 17:11 .imap.index
-rw------- 1 v-worst v-worst 10264 Jun 24 17:11 .imap.index.data
-rw------- 1 v-worst v-worst 2576 Jun 22 16:10 .imap.index.log
-rw------- 1 v-worst v-worst 1556 Jun 24 17:11 .imap.index.tree
drwx------ 2 v-worst v-worst 7168 Jun 24 17:11 cur
-rw------- 1 v-worst v-worst 18 Jul 9 10:10 dovecot-uidlist
drwx------ 2 v-worst v-worst 6656 Jun 24 17:11 new
drwx------ 2 v-worst v-worst 6144 Jun 24 17:11 tmp
tokyo# cat .Trash/.customflags
] Will NMH get Maildir support? I don't see it as highly likely, but with
] a major rewrite, perhaps. One way around the sort problem would be to
] hardlink all of the Maildir emails into an MH folder (directory), and
] allow manipulation of the files through the hardlinks for NMH while
] allowing Maildir access to other clients.
Interesting, but it would end up only allowing nmh to view the
world in a semi-read only state. (Delete things dont really go
away, changes only happen in the nmh side of things.)
] I haven't tried to mix Maildir and MH in procmail, but you might want to
] give something like this a try:
] * Subject: Test MH/Maildir
] mhtest/. mdtest/
I'll play around with this and see where it leads. The issue is
really that I want to manipulate the store at different times with
the two methods.
Mostly I was curious if others were interested in such a project.
A friend (who uses nmh) has suggested that I get nmh to support
IMAP. Interesting idea, but probably fraught with more pitfalls.