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 fringe of supported behavior. 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. Might rcvstore be keeping a lock on the sequence file for too long? It just occurred to me that what I previously thought was mime-add-hook running slow is probably the script waiting for filelocks; although `mhparam lockmethod` reports "none" (David says the last bit is a bug he's looking into) dl>> with "pseq: 30" instead of "cur:" The workaround is including the dl>> sequence itself in the messages to add to the sequence i.e; dl>> mark unseen $MSG -add -seq unseen -nozero dl>I don't see why that would be necessary. Don't I know it, but it works... _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
