nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] mhshow -file /tmp (!)


From: Ken Hornstein
Subject: Re: [Nmh-workers] mhshow -file /tmp (!)
Date: Fri, 17 Mar 2017 21:39:11 -0400

>do i recall correctly that you're using a mac?

Yup, true.

> > And everything seems ok.  A quick system call trace reveals that the
> > error is coming back from read().  I suspect there are a lot of things
> > that are falling back to a "mangled" message being a single text/plain
> > part.  Can you just open directory files without any special magic on
> > your system?  It would be interesting to see the logic flow.
>
>yes, open(2) on linux is perfectly happy opening a directory.  but
>that's not the problem.  (your open() is succeeding too, right?)

I guess I should have been more specific; I believe you need to pass a
special flag to open(2) so you can actually READ directories.  But yes,
my read(2) is failing with EISDIR.

>i'd be curious to know which read() failed for you.  the first read on
>the opened directory is in read_more(), at m_getfld.c:443.  strace
>shows me that that read() is returning EISDIR, but that the fread()
>returns 0.  i have no clue why it might do that, but i also see that
>there's no error checking on that fread(), so i guess that's not the
>one that's failing for you.

Hm, actually ... I stepped through it with a debugger, and it IS the
one who is failing.

The basic flow is:

mhshow calls parse_mime()
parse_mime() calls get_content()
get_content() decides it's a message with a single text/plain part (default)
Then the MIME display routines are called, and you end up in open7Bit().

The part where YOU fail, "internal error (3)", I go past.  Because for me,
ct->c_end = 510 and ct->c_begin = 0 (which I guess is right?).  I end
up failing (for the second time) at mhparse:2251 (that's the read() in
open7Bit(); line number may have changed since 1.6).

It looks like c_end is set in parse_mime(); maybe different system behavior
there between Linux and MacOS X?  Not saying we don't need to fix something;
maybe the "right" fix is to properly bubble up read errors from m_getfld()?
Although ... ugh.  David should weigh in what we should do there.

--Ken



reply via email to

[Prev in Thread] Current Thread [Next in Thread]