[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
Re: [Nmh-workers] mhshow -file /tmp (!), Robert Elz, 2017/03/17