I'm thinking about the code modification. With the error-handling and
fallback when linking fails, I think what you want is a smaller modification
to refile (adding taking the message from stdin) then it is to rcvstore
(all the other stuff).
The code modification is not complicated.
Modifying rcvstore to deliver to multiple folders does not stray past the
original intent of rcvstore. Modifying refile to handle sequences (which
would be necessary to have the rcvstore behavior) is definitely outside the
scope of that tool.
What is really bothering me though is that if you give all the folders
on the one command line, you have to know them, i.e. build the list. This
isn't really the slocal idea.
I'm not using slocal. I need rcvstore to have this functionality.
The problem isn't really one of atomicity, and I can say that because
even doing this in one nmh command is not atomic. They interfere with
each other. The problem is not having a common location to achieve the
linking.
I don't understand this paragraph -- could you be more specific how a
rcvstore to multiple folders is going to interfere with other nmh commands?
Keep in mind that rcvstore does not manipulate the context (ignoring
sequences).
I also do not understand why you need a "common location" to achieve the
linking. Linking will only work if all the mail is on a single filesystem; if
it wasn't clear, I will state explicitly that this (and _any_ other solution
involving refile, etc.) will require that the seperate folders reside on the
same filesystem.
Nick
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers