>Nope, not mixed versions, but your guess is as good as mine as to what's up.
>I can poke around some more in the next few days/keep my eyes peeled.
A system call trace would probably be very illuminating.
___
Nmh-workers mailing list
Nmh-workers@nongnu
Nope, not mixed versions, but your guess is as good as mine as to what's up.
I can poke around some more in the next few days/keep my eyes peeled.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
>In fact, the more I think about it, the more I wonder WHAT is going
>on, exactly. The things you describe happening do not make sense to
>me. Since the unseen sequence is not modified until the very end of
>rcvstore, there should be nothing to remove from the unseen sequence
>during the hook ope
>I can save you the trouble; that's not going to change anything. All
>set_unseen does is modify the sequence status bit vector in the folder
>structure. The locks don't get released until seq_save() is called.
Actually it did solve the problem.
Sorry if I was not clear, the idea of moving it w
>The overall problem is that calling nmh commands inside the hook script
>was removing the message from the Unseen-Sequence*. Delaying that call
>until after the hook invocation is complete ensures that whatever operations
>are done in the hook, the message ends up in Unseen-Sequence after the
>pro
>>Of course, if you want to CALL mark inside of a hook, then all bets are
>>off :-) I'm unclear how we can make that better. I will note that rcvstore
>>can add messages to specific sequences, and there was a deprecated feature
>
>Nice! If that happens after add-hook we're 90% there.
>The only pr
>Of course, if you want to CALL mark inside of a hook, then all bets are
>off :-) I'm unclear how we can make that better. I will note that rcvstore
>can add messages to specific sequences, and there was a deprecated feature
Nice! If that happens after add-hook we're 90% there.
The only problem
>>My *intent* when adding the hook code was to allow external, non-nmh programs
>>to access the message store keeping track of changes. I added this code for
>>a specific purpose, and never thought about anyone executing nmh commands
>>inside of hook code. So I support Ken's conclusion that doing
Jerrad Pierce writes:
> >My *intent* when adding the hook code was to allow external, non-nmh programs
> >to access the message store keeping track of changes. I added this code for
> >a specific purpose, and never thought about anyone executing nmh commands
> >inside of hook code. So I support K
>My *intent* when adding the hook code was to allow external, non-nmh programs
>to access the message store keeping track of changes. I added this code for
>a specific purpose, and never thought about anyone executing nmh commands
>inside of hook code. So I support Ken's conclusion that doing so
Ken Hornstein writes:
> Hooks are a relatively new addition to nmh, and it was never really defined
> very well what you could expect to work inside of them. I am unsure how
> we can guarantee that you can safely modify nmh metadata INSIDE of a hook
> when running a program that also modifies nmh
>It looks like, when it finally comes out, nmh-1.6 will represent a
>revolutionary change it the way nmh deals with MIME.
>
>But, in the nearly two years since nmh-1.5, there have been many other
>important (at least important to me) improvements. For example, to sortm,
>mhbuld, mhstore, and messag
Norm wrote:
> So I wonder if I could prevail upon somebody to create and release an
> nmh-1.6-RC1. I can't -- way about my pay grade.
Instead of that, how about trying the sequence of commands below?
You probably have some of the packages already installed, such as
openssl and readline. Just ma
>kh>Well, think about what's going on. You're changing sequences in the
>kh>middle of an operation which is changing sequences. At a minimum you're
>kh>going to be on the fringe of supported behavior.
>
>But other than the explicit calls to mark and Previous-Sequence,
>sequences oughn't be being
It looks like, when it finally comes out, nmh-1.6 will represent a
revolutionary change it the way nmh deals with MIME.
But, in the nearly two years since nmh-1.5, there have been many other
important (at least important to me) improvements. For example, to sortm,
mhbuld, mhstore, and message sequ
Hi Jerrad,
> But other than the explicit calls to mark and Previous-Sequence,
> sequences oughn't be being touched...? And I thought commands were
> meant to open, close, reread sequences as needed rather than keep
> a long lock? This is add-hook from rcvstore, via slocal.
You might find strace(1
kh>Are you using 1.3 (ewww), 1.5, or post-1.5 for your nmh implementation?
1.5+dev pulled from master on Monday (2/24) morning
kh>Well, think about what's going on. You're changing sequences in the
kh>middle of an operation which is changing sequences. At a minimum you're
kh>going to be on the
>I suppose I could try, but I've not used a C debugger
>
>Hmm, on a hunch I just discovered that somehow the call to mhstore in
>mime-add-hook's for loop is the trigger... of course that's the raison
>d'etre of the script :-/
Well, think about what's going on. You're changing sequences in the
mid
Jerrad wrote:
> >Try feeding mhstore from a file instead of a message, something like:
> Alas, mhstore -file did not solve the problem;
Though it looks like mhstore causes the problem? I don't
understand why -file wouldn't solve it.
> I seem to have found a workaround that works, even with the
19 matches
Mail list logo
