[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] multiple folders to rcvstore

From: Joel Reicher
Subject: Re: [Nmh-workers] multiple folders to rcvstore
Date: Tue, 08 Nov 2005 17:50:39 +1100

> > 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.

You make some good points. The only solution that comes to mind is to
write the message to a canonical place so that you can share that location
across rules, use "refile -link", then as a final step remove the canonical
location. If I understand refile correctly, it uses a hardlink so the
removal won't harm the correct filings.

> 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.

Yes. This is a long-standing problem with rcvstore too. The first
rule which stores the message in the canonical location should probably
be a shell process that waits until any message stored there is removed.
slocal's wait time is sufficient for most situations, but if your mail
delivery is *really* busy you run the risk of a starvation problem.

slocal has a -file argument, as does refile, so you have the option of
doing this locking/canonical-store as a wrapper around slocal.

> 2) The ability to dynamically match a series of patterns on the fly, building
>    a list of folders where the message will be filed.

Canonical location takes care of this.

> 3) A message delivered into multiple folders must minimize disk usage by
>    utilizing hard links.

refile -link, I think. :)

As you said, however, all this might not be any better than your current
procmail solution.


        - Joel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]