neomutt @20191111_0+gdbm+idn+mutt does not read header cache properly

[arappe]

neomutt @20191111_0+gdbm+idn+mutt scrolls through entire header cache but then initiates request for full download of the entire cache from the server.

neomutt @20180716_1+gdbm+idn+mutt is able to scroll through the same exact header cache and then only request the newest few mail headers and initiate normal mutt functionality.

Same functionality loss observed on multiple Macs. Details: Catalina 10.15.1 / Xcode 11.2.1

Can work around by activating neomutt @20180716_1+gdbm+idn+mutt. Request restoration of cache header functionality in neomutt @20191111_0+gdbm+idn+mutt.

[mf2k (Frank Schima)]

In the future, please add the port maintainer(s) to Cc (port info --maintainers neomutt), if any.

[lbschenkel (Leonardo Brondani Schenkel)]

NeoMutt has had a recent big release, and I believe this is an upstream regression. Can you please submit this to ​https://github.com/neomutt/neomutt/issues?

[arappe]

Thanks for replying. I find that on yet another Mac of mine (also OS X 10.15.1 and Xcode 10.2.1) neomutt @20191111_0+gdbm+idn+mutt verifies the headers file properly and doesn't try to re-download it. So I think that means that some of my Mac Ports builds are not built right on the other two machines. The output from "neomutt -v" is identical on the install that works and the one that doesn't.

Here's what I tried on the non-working install.

port deps neomutt

uninstall neomutt

uninstall of each build, library, and runtime dependency listed.

install / upgrade of each dependency.

upgrade neomutt

No change. the nonfunctional install still doesn't parse the header file properly. port rev-upgrade finds nothing to do.

So this likely is neither a bug of neomutt nor of the Mac Port since I have it working on one computer. Any suggestions for how to root out the problem with my other installations would be very welcome. Thanks for your time.

[lbschenkel (Leonardo Brondani Schenkel)]

Thanks for the info. I still think that this may a bug upstream, and even if not you will receiver better help if you submit it at ​https://github.com/neomutt/neomutt/issues. MacPorts packaging sometimes can be the issue, but those cases are a bit rarer in comparison.

[lbschenkel (Leonardo Brondani Schenkel)]

Hi, is this still an issue?

[arappe]

Dear Leonardo,

Thanks for asking. I have done some more debugging. Yes, I still have the same problem. Working theory: neomutt caching fails if the INBOX folder is too big.

1. I did a fresh install of everything. (Mac with OS X 10.15.3)

% sudo rm /opt/local deleted /Applications/Xcode.app installed Xcode from App Store % sudo xcode-select --install installed macports % sudo port selfupdate % sudo port upgrade outdated % sudo port install neomutt +gdbm+idm+mutt

I find that every time I run mutt to get my work INBOX, it scans the header cache, rejects it, decides to get a new header cache, loads the whole header cache from the server, and says that it cannot open the inbox. On this same installation, several other things succeed: I can get header cache and body cache for a gmail account. (small, , 1GB) I can get header cache and body cache for a subdirectory of my work email. For example, I have one month's worth of mail stored in +INBOX/apr2013 (small, 50MB total for folder) So my only guess is that the 55 GB folder +INBOX is too big?

2. On another Mac, neomutt @20180716_1+gdbm+idn+mutt works for my full work INBOX. It scans the header cache, agrees that it's OK, only gets the few new headers since last run, and functions more or less as normal. I don't know how and/or have not been successful in compiling this old 2018 snapshot on the computer mentioned in point #1 above. I have followed instructions for how to acquire an old snapshot but I haven't been able to get it to work. (I'm sure I'd prefer that we get the current version to succeed rather than running back to this old snapshot anyway.) So this suggests that mutt can in principle handle this iNBOX and IMAP setup and etc. So I am just left with thinking that we have hit a size limit that was recently imposed? Just a guess.

I have been investigating moving my INBOX stuff into lots of subfolders. But if neomutt could be fixed to handle the full INBOX, that'd be ideal. Any questions for me? ideas to try?

Andrew

[arappe]

Dear Leonardo, I now find that the latest version works as advertised, providing header and body caching.

neomutt @20200626_1+gdbm+gpgme+idn+mutt (active)

I changed the cache configuration statements in .muttrc to exactly match the working ones (gmail and INBOX subdirectory). Here are my only changes to .muttrc:

diff .muttrc_new .muttrc_old

=================================================

25,27c25,27

< set header_cache=~/.mutt/cache/headers

< set message_cachedir=~/.mutt/cache/bodies

< set certificate_file=~/.mutt/certificates

---

set header_cache=~/.mutt-hcache/cache/headers

#set message_cachedir=~/.mutt-hcache/cache/bodies

set certificate_file=~/.mutt-hcache/certificates

86c86

< set index_format="%4c %6C %Z %d %-20.20F %s"

---

set index_format="%c %3C %Z %d %-20.20F %s"

272c272

< # set header_cache="~/.muttheaders3"

---

set header_cache="~/.muttheaders3"

275,276d274

<

< mailboxes = +INBOX

=================================================

Previously the header caching was going to .muttheaders3 and I wasn't doing body caching. I'm not sure what was wrong with the old config file. But these small changes got me back to work. Thank you for your help and interest!

Andrew

[lbschenkel (Leonardo Brondani Schenkel)]

I'm happy to hear it got solved for you. I'm closing this.