[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: Wed, 09 Nov 2005 09:10:20 +1100

> any arbitrary one, and create links in any additional folders. None of the
> locations are privileged. (Let's ignore how sequences would be specified, for
> now). To the filesystem, all links are identical; there is no preferred link.
> The fact that rcvstore is obtaining the message from stdin is not relevant
> here. (It will use that data to initially write the message to disk, but

OK, I concede this. I hadn't thought it through.

> > I think what Nicholas wants is essentially refile.
> I want rcvstore to multiple folders. refile takes an existing message and
> links it; I have an atomicity (again, from an nmh perspective) problem -- I
> want to store a message into multiple folders in a single nmh operation. I
> can already do what you've suggested, which is save the message initially and
> then refile. It works, but it is messy.

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

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.

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

I think I have a much simpler way to solve that now. Give rcvstore a
unique -sequence arg, e.g. one containing the procmail PID (I assume
procmail is invoked per message). After rcvstore completes, you'll have
the number where it stored that message, and you can then use refile.

I follow this up by making a proposal for slocal: add the PID to the
environment. That way some information can be shared across rules, and
still be specific to a particular message delivery.


        - Joel

reply via email to

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