[Dovecot] link() problem with dovecot-imapd

[Geo Carncross]

On Thu, 2004-09-02 at 15:06, Timo Sirainen wrote:
> Maildir standard says to use link(), but I suppose it could fallback to 
> rename() too.. Hmm. I'm just not sure if it's worth it to implement, 
> it's useless bloat for most people.

No it doesn't. It used to- the documentation supplied with qmail (and
the implementation that is qmail) use link()+unlink(), but the current
maildir specification (http://cr.yp.to/proto/maildir.html) simply refers
to "moving" the message without any regard to how that may be performed.

If the identifiers generated are guaranteed unique, then there isn't any
need to use link()+unlink(); you should be able to save a syscall by
just using rename().

Note, some silly unixes have made it difficult to get really unique file
names, which is probably why DJB used/promoted link()+unlink() himself,
and then later extended the delivery-identifier-format.

That said, maildir-implementations have to be NFS-aware, and that means
that rename() [because it clobbers] might return successful even though
it wasn't. I don't know of any NFS-implementations that do this, I'm
certain at least one networked-filesystem and/or implementation does
this, or could think it's a bright idea in the future...

Nevertheless, the desired effect is possible without changing dovecot:
If one is using a filesystem that lacks link() but actually has a
reliable rename() AND YOU TRUST DOVECOT's ABILITY TO GENERATE UNIQUE
IDENTIFIERS, you could use a small LD_PRELOAD/wrapper to replace link()
with rename() and disable "use hardlinks for copy" in dovecot...

-- 
Geo Carncross <geocar at internetconnection.net>
Internet Connection Reliable Web Hosting
http://www.internetconnection.net/