Thanks for bugging me about this again. You're right; I didn't fix it (and
I remember that I was very insistent that I was going to fix it before
releasing another version).
I've now added compensation code to mailbox.c to try unlinking and
relinking if the destination file already exists.
This is safe since the message hasn't been considered delivered until the
index file is updated, and if the index file was updated we wouldn't try
overwriting it.
Thanks,
Larry
--On Monday, January 15, 2001 04:41:50 PM +0000 John Holman
<[EMAIL PROTECTED]> wrote:
> Cyrus 2.0.9 - I don't know whether the problem was present in version 1.
>
> I think a simple example will be the easiest way to describe the general
> problem, which can probably cause trouble in other circumstances.
>
> Consider copying messages from one mailbox to another. Suppose that
> initially the source mailbox initially contains 100 messages with files 1.
> to 100., and the destination mailbox is empty. Now I execute an IMAP copy
> command to copy all messages from the source to the destination folder.
> If the copy command fails to complete I've noticed that some new message
> files can be left in the destination folder. So let's say that inbox.dest
> now contains new files 1. to 50. - though of course these are not visible
> through the IMAP protocol because the command did not complete. The new
> files will generally be hard links to the same inodes as files 1. to 50.
> in the source mailbox.
>
> This is a dangerous situation, and the messages in the *source* mailbox
> are about to be corrupted. This is because the next message to be copied
> to the destination mailbox will be written to file 1. As this is linked
> to the same inode as file 1. in the source mailbox, the first message in
> the source mailbox has its contents replaced with the new message. In the
> end the first 50 messages in the source folder will be lost.
>
> Truss shows that an attempt is made to link the file, but it fails in this
> case because the new link already exists (EEXISTS). The destination fd is
> then opened and written to. I suspect (but haven't verified) that the
> relevant code is in mailbox_copyfile() in mailbox.c. Perhaps if the new
> link does already exist, that link should be deleted and a new file
> created to avoid changing the contents of an inode in use elsewhere.
>
> By the way, this is certainly not just a theoretical problem - it happened
> to me for real last week. And because some of the messages in my source
> mailbox shared inodes with messages belonging to others, they lost
> messages as well.
>
> Also, I'd be interested to know under what circumstances the copy command
> *can* fail to complete in this way. One sure recipe I have found is to set
> "Servers timeout" in Outlook Explorer 5.5 to 30s and then copy a large
> mailbox (3000 messages).
>
> Incidentally I've noticed this is accompanied by syslog message such as
> Jan 15 16:02:48 eta master[6827]: process 26886 exited, signaled to death
> by 14
> What exactly does this mean?
>
> Thanks, John.
>
> --
> John Holman
> Queen Mary. Universitly of London, UK
>
>
