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@internetconnection.net Internet Connection Reliable Web Hosting http://www.internetconnection.net/