Coda File System

Re: Application-Specific Resolution

From: Jan Harkes <>
Date: Thu, 20 Apr 2006 08:05:20 -0400
On Thu, Apr 20, 2006 at 11:17:13AM +0200, wrote:
> On Wed, Apr 19, 2006 at 02:27:39AM -0400, Adam Wolbach wrote:
> > I would like to poll the community to find out what the most common and 
> > annoying conflicts encountered are, in order to build a list of target 
> > applications to write resolvers for. For example, I have already 
> > implemented an ASR that automatically merges diverging copies of 
> > OpenOffice v1/2 documents and spreadsheets. What other applications 
> > (ideally Linux or Windows) cause the biggest headaches for Coda users?
> maildirs (mutt?)
> It seems that unlinking a snatched-away file leads to a conflict,
> while possibly it shouldn't?

Most maildir problems are either implementation bugs/problems or simply
unhandled cases during resolution.

Typical sequence for incoming mail is to create the file in tmp and move
it over to new. Then the mail clients read new and possibly move it over
to cur. The problem here is that when we have multiple server and one
server was down during delivery, the mail client looks at new and
notices a difference and triggers resolution. The resolution then fails
because the file doesn't exist on all servers. This is because the
create operation is in the log for 'tmp' but we haven't resolved that
directory yet. In this case both tmp and new are marked as a conflict
Fixing this conflict is trivial if you start by repairing tmp and then
new, and very painful if you try to repair the other way around.

Another problem that hits me are mailboxes with > ~4096 emails, those
end up hitting the insanely low directory size limit of 256K. Clearly an
implementation problem, which is why I still deliver most high traffic
mailinglists (and spam) to local disk, almost everything else is
delivered straight into Coda.

I think I already downgraded the severity of unlink/unlink conflicts a
long time ago. Strictly speaking these are conflicts, but the intent of
the user was clearly to remove the file. However there was a bug (fixed
in 6.0.13/14) how the unlink operation was packed in the reintegration
log which would result in marking the parent directory as a conflict.

Received on 2006-04-20 08:07:35