> Why not just call rcvstore multiple times with the same input? More than > one matching line in .maildelivery with a result of A or R would do > this.
I don't want to duplicate the storage used by the messages; the linking is a must. > If it's the linking that's important to you, call rcvstore once and then > use refile -link. You could put all that in the one action of a > .maildelivery line if you wanted. How can I do this and allow concurrent access to the folders? (I don't think) rcvstore will tell me what message it just assigned, so refile will only work if the current message hasn't changed. That won't be sufficient, as most of the mail delivery is occurring in the background as I work. In addition, as I build up the list of folders dynamically based on the message, I would rather not have n permutations of delivery rules. Finally, even if rcvstore does tell me the message it delivered into, if I have to call refile multiple times with that msg will be no better than my current procmail solution. I don't currently use slocal for delivery, but I suppose I could. I think it will also need a code change to do what I want. I think I need: 1) "Atomic" (from an nmh perspective) delivery of a message into multiple folders. The delivery of a message must not interfere with other operations or prevent those operations from occurring. 2) The ability to dynamically match a series of patterns on the fly, building a list of folders where the message will be filed. 3) A message delivered into multiple folders must minimize disk usage by utilizing hard links. For example, I want to save commit traffic, list traffic, and have messages delivered to my inbox. Imagine the case where a single message falls under all three categories. In other cases, a message might match only a single category. Are my needs more clear? If so, do you still think there is a way to do this with a set of .maildelivery rules? If so, please forgive my ignorance; perhaps you (or some other kind person) could set me a private email with additional instructions. Nick _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
