On Sun, 18 Mar 2012 22:15:17 -0400, Ken Hornstein said:
> > Looking at things ... it may be a simple fix, actually. I wasn't
> > envisioning any changes to m_getfld(), that's for sure.
>
> Alright, I think I've got a fix in there, and I've got a test which exercises
> the bug. I was right that th
>I'm using the latest source (and autogen.sh) now, and scan does work
>properly. Thanks.
What a relief! Glad it works! I was totally stumped, because I was
sure I fixed it.
I know that you know this now, Steve, but for everyone else: autogen.sh,
at the top level of the source code tree, should
> >Ken, sorry, hate to say it, but...
>
> Hm. I just now tested it, and it works alright. And the test
> message fails with an older version of scan.
>
> Does "make check" pass the test/inc/test-inc-scanout test? If it does,
> can you make available for me one of the problem messages?
>Ken, sorry, hate to say it, but...
Hm. I just now tested it, and it works alright. And the test
message fails with an older version of scan.
Does "make check" pass the test/inc/test-inc-scanout test? If it does,
can you make available for me one of the problem messages?
--Ken
__
> > Looking at things ... it may be a simple fix, actually. I wasn't
> > envisioning any changes to m_getfld(), that's for sure.
> Alright, I think I've got a fix in there, and I've got a test which exercises
> the bug. I was right that the fix was simple, but I had to take into
> accoun
> Looking at things ... it may be a simple fix, actually. I wasn't
> envisioning any changes to m_getfld(), that's for sure.
Alright, I think I've got a fix in there, and I've got a test which exercises
the bug. I was right that the fix was simple, but I had to take into
account all of the ways
> > Looking at things ... it may be a simple fix, actually. I wasn't
> > envisioning any changes to m_getfld(), that's for sure.
>
> I stared at it for a few moments and thought that removing
> the scansbr.c snippet that you posted might do it, but I
> really don't know.
No, no joy there.
> >I agree (with the re-write, I've never witnessed the problem).
>
> I assume you mean WITHOUT the rewrite, because nobody's re-written
> m_getfld last time I looked :-)
Right.
> Looking at things ... it may be a simple fix, actually. I wasn't
> envisioning any changes to m_getfld(), that's for
>I agree (with the re-write, I've never witnessed the problem).
I assume you mean WITHOUT the rewrite, because nobody's re-written
m_getfld last time I looked :-)
It's sort of Steve's setup that triggers it; not only does he have a bunch
of Received: headers, but a huge spam score report, a coupl
>>> Punt until the m_getfld() re-write
If this was a five-9s thing, like 99.999% working, then I'd be down for that.
But it's not, and maybe the fix is fairly simple?
>> If we guess wrong, that would result in one extra read in some cases.
Do I understand correctly that we're wringing our ha
Ralph wrote:
> Punt until the m_getfld() re-write. It's annoyed me for years, it can
> continue a while longer.
I agree (with the re-write, I've never witnessed the problem).
The code after Ken's excerpt goes directly into the io buffer.
It's in the caller, not m_getfld().
David
_
Hi Ken,
> Thoughts?
Punt until the m_getfld() re-write. It's annoyed me for years, it can
continue a while longer.
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
>Since I started using mh-v, for about two months, I've been keeping a
>pretty close eye on making sure scan and mhshow work perfectly. This
>week collected four msgs where the decoding %{body} is truncated after 6
>to 16 characters with v1.2 and v1.4!
Okay, Steve was nice enough to give me a tes
> Could someone forw me one of the affected messages? I'll be glad to track
> it down. Also, if you could include an MD5/SHA1 checksum of the message
> I can be sure on this end to recreate it exactly?
Will do, off list, in a sec.
steve
--
___
Nm
> Been seeing this, haven't had a chance to track it down. Looking at exmh's
> .xmhcache files, I have 145,141 total messages listed in .xmhcache entries,
> and
> the bug is affecting 3,266 of them. So there's an anectodal value for the
> frequency.
...but isn't the body sometimes smaller
>Wow. So I'm not hallucinating (at least not this time :)
>
>Been seeing this, haven't had a chance to track it down. Looking at
>exmh's .xmhcache files, I have 145,141 total messages listed in
>.xmhcache entries, and the bug is affecting 3,266 of them. So there's
>an anectodal value for the= freq
On Fri, 16 Mar 2012 16:46:46 CDT, ra...@hep.wisc.edu said:
> Can someone/anyone replicate? Test with the msg from Ken to this list today,
> March 16 2012 at 11:35:44 -0400?
Wow. So I'm not hallucinating (at least not this time :)
Been seeing this, haven't had a chance to track it down. Looking
Since I started using mh-v, for about two months, I've been keeping a pretty
close eye on making sure scan and mhshow work perfectly. This week collected
four msgs where the decoding %{body} is truncated after 6 to 16 characters
with v1.2 and v1.4!
See examples (300, 500-502) after my sig.
Can
18 matches
Mail list logo
