Mutt stops showing mail contents

[Matthias Apitz]

El día martes, diciembre 22, 2020 a las 02:16:56a. m. +0100, Matthias Apitz escribió:

> El día lunes, diciembre 21, 2020 a las 06:55:18p. m. +0100, Josef Wolf escribió:
> 
> > On Mon, Dec 21, 2020 at 01:32:47PM +0100, Matthias Apitz wrote:
> > > Linux has strace(1) (at least it could be installed). I'd start mutt
> > > below strace, like that:
> > > 
> > > $ strace -o mutt.tr -f -t mutt .....
> > 
> > OK. So here I have attached two strace snippets while mutt is showing a mail
> > from a Maildir folder. One snippet shows opening a mail where the body is
> > shown and one where the body is not shown.
> > 
> > Below is a diff of those two snippets. The interesting part is in the second
> > hunk. This is where the header has been read (every lseek(4,0,SEEK_CUR)
> > corresponds to one header line).
> > 
> > After the header has been read, the good invocation will lseek(4,0,SEEK_SET)
> > in order to re-read the Maildir file. Then it creates a temp file, dumps the
> > contents to this tempfle, and closes it. Then it reopens the file, deletes it
> > and reads the contents back.
> > 
> > The bad snippet skips all this. It just closes the Maildir file.
> > 
> > Both snippets and the diff are attached to this mail with un-shortened
> > strings. Here is the diff with shortened strings for readability:
> > 
> 
> Smells like a bug in the mutt code you are using on your system. Can you
> compile and test an actual code of the original source?
> 

With more time, I looked in detail into the two straces and compared
what's going on. The mail in the file 

/home/jw/Maildir/.ML.mutt/cur/1608410405.M316715P6694.raven.wolf.lan,S=4769,W=4880:2,S"

is 4769 bytes in size (headers and body). In the good case mutt reads
first 4096 bytes, rewinds the fd, reads the 4096 bytes again
and then the additional 673 bytes. See below. The small
number at the beginning of the line, like 17, 21, 22, ... is the line
number of your files.

In the bad case it reads *only* the first block of
4096 bytes and then closes the file descriptor. Somehow it must get the
opinion that the rest is not worth to read. But this "opinion" is not
based on a sys call result.

Why?

And what is this repeated asking with lseek(2) from line 22 to 89 in
both cases with

22617 lseek(4, 0, SEEK_CUR)    = 4096

always getting "yes, next byte to read is number 4096" I don't know where
maildir files in mutt are handled. Maybe it's time to look into the
source there...

	matthias


good case:

    17  22617 openat(AT_FDCWD, "/home/jw/Maildir/.ML.mutt/cur/1608410405.M316715P6694.raven.wolf.lan,S=4769,W=4880:2,S", O_RDONLY) = 4

    21  22617 read(4, "Return-Path: ....", 4096) = 4096
    22  22617 lseek(4, 0, SEEK_CUR)    = 4096
    ...
    (rewinds fd 4):
    92  22617 lseek(4, 0, SEEK_SET)    = 0
    93  22617 read(4, "Return-Path: ....", 4096) = 4096
    ...
    103  22617 read(4, " > hours or even days, ...", 4096) = 673


bad case:

    17  22617 openat(AT_FDCWD, "/home/jw/Maildir/.ML.mutt/cur/1608410405.M316715P6694.raven.wolf.lan,S=4769,W=4880:2,S", O_RDONLY) = 4

    21  22617 read(4, "Return-Path: ....", 4096) = 4096
    22  22617 lseek(4, 0, SEEK_CUR)    = 4096
    ...
    92  22617 close(4)                 = 0
    93  22617 write(3, "Date: Sat, 19 Dec 2020 21:26:55 +0100\nFrom: Josef Wolf <jw at raven.inka.de>\nTo: mutt-users at mutt.org\nSubject: Re: Mutt stops showing mail contents\nUser-Agent: Mutt/1.10.1 (2018-07-13)\n\n", 182) = 182

-- 
Matthias Apitz, ✉ guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) 
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)