Re: [Nmh-workers] use of 'Unseen-Sequence' with rcvstore (Was: Re: refile handling of corrupt .mh_sequences)

[Ken Hornstein]

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

No.  The 3 big post-1.5 locking changes were:

- The ability to select the locking algorithm at runtime.
- The ability to configure the spool locking and data locking algorithms
  seperately.
- Locking across the complete read/write cycle.

The last was arguably to fix a deficiency in the fact that two programs
running simultaneously could wipe out changes that they made to the sequence
file, depending on who won the race.  So was that "broken"?  Only in the
sense that there was never any guarantee you could run two MH programs
at the same time :-)  But like I said, these changes aren't relevant
for the sequence file corruption issue (well, there WAS a problem where
one of the locking implementations would unlock the sequence file BEFORE
it called fclose(), but that's a minor detail :-) ).

If you looking at the mailing list archives for March of 2013, you can
see where this was all hashed out.

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

Yow, _dxmail_?  From Ultrix?  Is Ultrix even a thing anymore? :-)

Okay, I understand your point.  We should offer a linkable library.
It sucks that we don't.  But that's a huge undertaking, considering
that libmh.a calls "adios()" all over the place, and that's just for
starters.  Also ... I am skeptical that the developers of all of these
MUAs and IMAP servers would be willing to invest the time to switch to
a nmh-supplied library even if one was available.  I mean, the Claws Mail
folks can't be bothered to throw a few fcntl() calls in their sequence
writing code; switch over to a new library?  I don't see it happening.
But I'd be glad to be proven wrong!

--Ken