On Tue, 8 Jun 1999, Marc Haber wrote:
> How about this:
> - exim reads the spool file
> - exim feeds the spool file's content to the filter program
> - exim reads the filter's output back
> - exim writes that output to a different file (that is also locked)
> - exim deletes the old spool file
> - exim renames the new file to the old name.
Further -- I've just seen the fatal flaw in this. It goes as follows:
. Process A is playing this game. It opens the old file, locks it,
writes the new file, and locks it.
. Process B (an Exim queue runner, say) comes along, opens the old file.
. Process A now renames the new file as the old file and closes the file
descriptor for the old file. This gives up the lock on the old file.
. Process B now tries to lock the open file (the old one) and
successfully gets the lock, so goes on to try to deliver the message,
using the wrong file.
Oops.
As I suspected initially, it looks as though this cannot be done without
re-implementing the locking completely.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
