>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
>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
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
>Try feeding mhstore from a file instead of a message, something like:
Alas, mhstore -file did not solve the problem; mhfixmsg already was using
implicit -file, $1 is an absolute path
Okay, some more odd evidence
"WORKING" state w/o mhstore
>From within mime-add-hook mark reports this, both befo
Jerrad wrote:
> 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 :-/
Try feeding mhstore from a file instead of a message, something like:
FILE=`mhpath $MSG`
for PART in `
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 :-/
Hopefully it's not too hard to follow:
#!/bin/sh
VERSION=0.05
#Diagnostic m
> The only difference is ctxpath, which is to be expected since
> MHCONTEXT is set in one instance. I've also unsuccessfully tried a
> workaround of copying the sequence to another, then using mark -seq
> unseen tmpseq $MSGNUM
Ken's theory seems most likely. Can you step through in a debugger
aft
The only difference is ctxpath, which is to be expected since MHCONTEXT
is set in one instance. I've also unsuccessfully tried a workaround of
copying the sequence to another, then using mark -seq unseen tmpseq $MSGNUM
___
Nmh-workers mailing list
Nmh-wo
>Initial .mh_sequences
> cur: 15
> pseq: 1-17
> unseen: 15-17
>
>Called in mime-add-hook if Unseen-Sequence is defined
> mark 18 -nozero -add -seq unseen +/home/user/Mail/folder
>
>Final .mh_sequences
> cur: 18
> pseq: 18
> unseen: 18
Hm. I suspect there may be an interaction between the
Jerrad wrote:
> In trying patch the last few nits in MIME-hooks, I seem to uncovered an
> odd issue with mark. Despite the default behavior being to not zero a
> sequence on -add, mark is clearing the sequence, even when -nozero is
> explicitly given.
>
> However I only see this behavior from mar
In trying patch the last few nits in MIME-hooks, I seem to uncovered an
odd issue with mark. Despite the default behavior being to not zero a
sequence on -add, mark is clearing the sequence, even when -nozero is
explicitly given.
However I only see this behavior from mark within add-hook. The hook
24 matches
Mail list logo
