Sorry, everybody. Owing to my ignorance of the way Unix works, I have
made a major mistake in the coding for parallel remote delivery, which
is the cause of the message corruption that Pete Ashdown reported. How
it escaped notice before, I really don't know. I did do all sorts of
tests, but I suppose I used small files, which might not have provoked
it.
If you are running Exim with remote_max_parallel set to a value greater
than 1, please put on the patch below. I have placed a copy in the
distribution directory as well. If you have not changed the default
value of remote_max_parallel, you do not need the patch.
Philip
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
*** exim-1.62/src/deliver.c Wed Apr 16 14:34:46 1997
--- src/deliver.c Wed Jun 25 10:41:14 1997
***************
*** 3382,3387 ****
--- 3382,3403 ----
debug_pid = getpid();
DEBUG(1) debug_printf("Remote delivery process started\n");
+ /* This process has inherited a copy of the file descriptor
+ for the data file, but its file pointer is shared with all the
+ other processes running in parallel. Therefore, we have to re-open
+ the file in order to get a new file descriptor with its own
+ file pointer. We don't need to lock it, as the lock is held by
+ the parent process. There doesn't seem to be any way of doing
+ a dup-with-new-file-pointer. */
+
+ close(deliver_datafile);
+ sprintf(spoolname, "%s/input/%s-D", spool_directory, message_id);
+ deliver_datafile = open(spoolname, O_RDWR | O_APPEND);
+
+ if (deliver_datafile < 0)
+ log_write(0, LOG_MAIN|LOG_PANIC_DIE, "Failed to reopen %s for remote "
+ "parallel delivery: %s", spoolname, strerror(errno));
+
/* Close the unwanted half of the pipe, set the process state,
and run the transport. */
