On Fri, Nov 03, 2000 at 01:29:47PM -0500, Jan Harkes wrote:
> Coda does not and will not support cross-directory links. However, the
> maildir specification states that a delivery should create a file in
> tmp/, hardlink it to the same name in new/, and then remove the entry
> from tmp/.
> 
> This is, I assume, to work around the fact that rename on NFS is not
> guaranteed atomic and a file could get _lost_ during the rename operation.

On any filesystem, rename will delete the target if it exists.  Maildir
is designed to eliminate the possibility of losing messages during
delivery.  If there was an alternate method of moving a file from one
directory to another that would fail if the target existed, it would be
preferable, but such an interface doesn't exist.

> So I've modified procmail and mutt, my email reader, pretty much like
> this;
> 
> 	err = link(from, to);
> +	if (err == -1 && errno == EXDEV) {
> +	    /* this may be Coda, try again using rename */
> +	    err = rename(from, to);
> +	}

Sounds like a good idea.  I'll modify my own mail software to do this.

> This patch was accepted and integrated by the mutt developers,

When does mutt need to deliver to a maildir?

> but maybe
> someone should at some point make similar patches for qmail and attempt
> to convince DJB to update the maildir specification.

I can state fairly confidently that this just won't happen.

> And there is a hard to fix Coda resolution bug which hits when a server
> was down during maildelivery. When the new directory is resolved before
> the tmp directory, the file doesn't yet exist on the second server as
> the initial create and store haven't been resolved yet, and both
> directories are marked as in-conflict. When the tmp dir is resolved
> first everything is fine, but the mailcheckers are ofcourse only
> checking the new directory.

I'm a little fuzzy on what the impact of this problem is.  Does this
mean that any mail delivery done while one server of a Coda VSG will
cause a conflict once that server is brought on-line again?  That seems
a fairly large problem.
-- 
Bruce Guenter <bruceg@em.ca>                       http://em.ca/~bruceg/