[Dovecot] link() problem with dovecot-imapd
geocar-dovecot at internetconnection.net
Fri Sep 3 17:52:54 EEST 2004
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
More information about the dovecot