Disable creation of hardlinks in message store

[Ken Murchison]

Simon Matter wrote:

>>Simon Matter wrote:
>>
>>
>>>>I've tried to get rid of hardlinked files in our cyrus spools to make
>>>>partial mailbox restores easier and more safe. My first idea was to set
>>>>"singleinstancestore: no" in imapd.conf and make all payload files
>>>>independant from each other. Unfortunately I realized later that while
>>>>incoming messages are stored in independant files, the IMAP COPY command
>>>>still creates hardlinked message files. Of course there is nothing wrong
>>>>with singleinstancestore because the manpage clearly states that only
>>>>delivery via lmtp/nntp is affected.
>>>>I have now looked at the code and found that mailbox_copyfile() has a
>>>>nolink parameter which controls the copy/link behaviour. My idea was to
>>>>create a new config option to disable hardlinks completely.
>>>>
>>>>My questions:
>>>>- is such an option a very bad idea?
>>>>- does such a patch already exist somewhere?
>>>>- what's the best name of a new config option?
>>>>- is there a chance to have such a patch accepted into the distribution?
>>>
>>>
>>>I'd like to include the following patch into my cyrus-imapd rpm packages
>>>to address the issue mentioned above. While testing it on a test box it
>>>seemed to work very well. Do the cyrus developers see any possible
>>>problem
>>>with it?
>>
>>Actually, your patch affects ALL mailbox_copyfile(), which means that
>>messages won't even be hardlinked from the stage./ to the destination
>>mailbox.  I don't think we want to do this, since this will hurt
>>performance for all messages deliveries (even single recipient messages).
> 
> 
> That's why I was asking whether it's a good idea. IIRC mailbox_copyfile()
> is also used to handle other files, not only message files. So my solution
> was a dirty hack.
> 
> 
>>IMO, singleinstancestore *should* also govern IMAP COPY (does anyone
> 
> 
> That's what I expected first but found that it's only implemented for
> incoming messages for unknown reason. Your proposed solution looks like
> the way to go.

Right.  I'm assuming that was an oversight, not a design decision.  As 
soon as I get a thumbs up from Derrick, I'll commit the patch.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html