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
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers