On Fri, 15 Jan 2010, martin f krafft wrote:
also sprach Asheesh Laroia <ashe...@asheesh.org> [2010.01.14.2112 +1300]:
Sure. But the MDA doesn't need to do the commit immediately. Since
(presumably) we're using Maildir, the MDA on the mail receiving
server is going to generate filenames that won't cause conflicts.
So it's okay to leave the files uncommitted.
So when does the commit happen?
When I did the "git merge", git would create the Maildir files in
This might be something that the Git people could address if it was
brought up on the mailing list. Then again, it might not be possible
without going via a temporary file, which I doubt will fly.
A temporary file + rename() is the only way, as far as I know.
I suppose that I never actually considered merges on the IMAP server
side, but obviously the IMAP server has to work off a clone, and that
means it needs to merge.
It's not "merge" that's unsafe; that just builds a tree in the git index
(assuming no conflicts). It's the ensuing process of git writing a tree to
the filesystem that is problematic.
I could probably actually write a wrapper that locks the Maildir while git
is operating. It would probably be specific to each IMAP server.
Note that this mean git is fundamentally incompatible with Maildir, not
just IMAP servers.
Dovecot would notice the file in ~/Maildir/cur/ and think, "This file
must be ready!" So it would parse it even though git hadn't finished
writing it. This caused me to only see partial headers in Alpine since
Dovecot parsed it before it was a complete message.
I wonder if a custom merge driver could address this to properly use
…/tmp/ to assemble the message and only then move it.
I don't think a merge driver can do it for the reason stated above.
I always turn to the sports pages first, which record people's accomplishments.
The front page has nothing but man's failures.
-- Chief Justice Earl Warren
notmuch mailing list