|Subject:||Re: [Nmh-workers] use of 'Unseen-Sequence' with rcvstore (Was: Re: refile handling of corrupt .mh_sequences)|
|Date:||Mon, 20 Jan 2014 08:51:23 -0800|
|User-agent:||Postbox 3.0.8 (Windows/20130427)|
Ken Hornstein wrote:
... There are post-1.5 locking changes, but that wouldn't affect this. ...
was something still broken after my patch to the locking to fix the "unseen" problems i was getting from my cron jobs? (i wasn't trying to manipulate the sequences files directly; i was running MH commands in both foreground and background at the same time, and the sequences file was getting clobbered.)
Your locking issues are almost certainly caused by Claws Mail. I really wish the Claws Mail folks wouldn't say that their mail is stored in MH format, as that implies that it's safe to use with MH tools; obviously it isn't.
claws mail has company. xmh and dxmail both had to reach directly into the ~/Mail directory because there weren't MH commands to perform even operation they needed. i havn't looked at vmh or mh-e to see if they do likewise. if MH offered a linkable library full of folder and message manipulation functionality that was callable by C, wrappable by C++ and Perl and so forth, and used internally by all of the "uip" commands in MH itself, then a lot of the tension around things like locking would disappear.
i've hacked the old u-w "imapd"'s MH support a few times, and, it does _everything_ using readdir() and open() and so forth, it forks no MH utilities at all. butchery, to be certain. and, it never worked right because MH can't meet the requirement for long-term stable message numbering. (i think mark did that on purpose, but i never asked him, and now it's too late.)
just a reminder that refactoring MH to move all the directory/file/locking logic into a library, would have tremendous side benefits.
|[Prev in Thread]||Current Thread||[Next in Thread]|