> Sequences is the main (only?) visible effect, but if you have a look > at the code for folder_addmsg() you'll see it's an infinite loop that > keeps trying to add a message to the next number in the sequence. If I've > understood it correctly, it's written like this because there is always > the possibility that a message has been dropped in by some other process > between choosing a message number and linking the message there. > > The design does not depend on, or even desire, atomicity.
This doesn't matter for the non-failure case. rcvstore creates a temporary file, T, and stores the message data there. folder_addmsg then links to T. Expanding this from a single call to multiple calls to folder_addmsg won't change anything, if there are no failures. I see no reason not to just ignore the multiple filesystems problem -- rcvstore will act the same as refile -- there are no guarantees as to whether the files are linked or copied. See the comment in uip/refile.c:392. In the failure case, however, there is a problem -- if some process were to pack the messages in a folder, recovery (as I had planned -- simply removing the previously created messages) would not be possible. This same problem exists in refile today. In fact, the current refile will simply exit prematurely when an error is encountered; it makes no effort to clean up after itself for a partial success. I'll have to think about whether there is some way we could properly clean up, unless people are comfortable with the refile "guarantees." (In which case, an error will be returned to the caller, but some messages may have been created). Nick _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
