On Fri, 15 Jan 2010, martin f krafft wrote:

> also sprach Asheesh Laroia <asheesh@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
>> ~/Maildir/cur/... non-atomically.
>
> 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.

-- Asheesh.

-- 
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