Re: header_cache
On 2017-09-02 11:52, Kai Weber wrote: > > > Error in /home/kai/.config/mutt/muttrc, line 13: header_cache: > > > unknown variable > > > source: errors in /home/kai/.config/mutt/muttrc > > > > Is this also the case if you build neomutt from source? > > Yes, Neomutt also has this problem. > > > This looks like a consequence of the choices made at build time. > > A plain "./configure --prefix $HOME/.local" results in the > header_cache error. Your suggestion to configure --with-kyotocabinet > helped. It was Kevin who suggested that. Here is the command I used to build my gentoo package [1]: ./configure --disable-lua --disable-notmuch --enable-gpgme --with-gdbm --without-mixmaster --without-tokyocabinet --without-kyotocabinet --without-qdbm --without-bdb --without-lmdb --without-idn I believe you simply need to configure _at least one_ of the database backends, it is not done automatically. [1] rsync://very.loosely.org/foolinux/mail-client/neomutt/neomutt-20170707-r1.ebuild -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet.
Re: header_cache
On 09-01-17, Ian Zimmerman wrote: On 2017-09-01 07:51, Kai Weber wrote: BTW, with either NeoMutt or Mutt 1.8.3 I get Error in /home/kai/.config/mutt/muttrc, line 13: header_cache: unknown variable source: errors in /home/kai/.config/mutt/muttrc Is this also the case if you build neomutt from source? Yes, Neomutt also has this problem. This looks like a consequence of the choices made at build time. A plain "./configure --prefix $HOME/.local" results in the header_cache error. Your suggestion to configure --with-kyotocabinet helped. Thanks
header_cache
On 2017-09-01 07:51, Kai Weber wrote: > BTW, with either NeoMutt or Mutt 1.8.3 I get > > Error in /home/kai/.config/mutt/muttrc, line 13: header_cache: > unknown variable > source: errors in /home/kai/.config/mutt/muttrc Is this also the case if you build neomutt from source? This looks like a consequence of the choices made at build time. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet.
Re: header_cache for mbox
On Thu, Jul 16, 2015 at 05:37:46PM -0700, Ian Zimmerman wrote: > On 2015-07-16 18:50 -0500, Derek Martin wrote: > > > > for lseek() to be useful, you need to know where to lseek to > > > which you wouldn't in this case (if you want reliable parsing). > > > > That's easy though, obviously you need to fully parse unread messages, > > but once they're parsed, you just cache the offsets. > > What about deleting messages? What about editing (which mutt allows) or > rethreading? Any of these actions will invalidate the offsets. Delete may or may not (it just sets a flag--I've long thought that mbox should have a fixed-width flag header so this can just be overwritten in place); but that need not necessarily be written out until the user syncs--a natural time to do a reparse. Expunging messages clearly would, as well as editing... but those operations are relatively rare. You'd need to reparse anyway, so... just do that. But you only need to reparse from the first modified message, so keeping the cache saves you some work even in that case. With mbox's typical use cases, it's far more likely that you'll modify messages near the end of the file than near the beginning, so usually this won't be a very costly operation. With very large mbox mailboxes, the time savings would be HUGE for typical usage patterns. The downside is, it's a lot more complex. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgp8rPb0s84TZ.pgp Description: PGP signature
Re: header_cache for mbox
On 16.07.2015, Heinz Diehl wrote: > I'll recompile without hcache and report back. Ok, done. Still, hcache is a huge improvement in the way I reported in my other mails.
Re: header_cache for mbox
On Thu, Jul 16, 2015 at 08:00:34AM +0200, Heinz Diehl wrote: > On 15.07.2015, Will Yardley wrote: > > Did you time the load with header caching disabled as well? > > No, in fact I didn't. > > > I've found that opening an uncached folder, or a folder where the cache > > is very out of date, sometimes can take a bit longer (while the cache is > > being built, presumably), but loading it again tends to be faster. > > I'll recompile without hcache and report back. I think you don't need to compile without it; just unset $header_cache. Of course, db library linked against and filesystem will affect the speed of reading the mailbox and building the cache, so the results may differ drastically from person to person. w
Re: header_cache for mbox
On 2015-07-16 18:50 -0500, Derek Martin wrote: > > for lseek() to be useful, you need to know where to lseek to > > which you wouldn't in this case (if you want reliable parsing). > > That's easy though, obviously you need to fully parse unread messages, > but once they're parsed, you just cache the offsets. What about deleting messages? What about editing (which mutt allows) or rethreading? Any of these actions will invalidate the offsets. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: header_cache for mbox
On Wed, Jul 15, 2015 at 09:34:25AM +1000, m...@raf.org wrote: > Derek Martin wrote: > > > On Tue, Jul 14, 2015 at 08:23:25PM +0200, Heinz Diehl wrote: > > > On 14.07.2015, Kevin J. McCarthy wrote: > > > > With mbox, I guess the designers thought there wouldn't be that much of > > > > a speed improvement > > > > because it's just a sequential read of a single file. > > > > > > That sounds reasonable. > > > > Except, as far as I can tell, it isn't. I see no reason hcache could > > not significantly speed up scanning mbox folders as well, at least on > > any system that supports lseek() or similar (which I imagine is any > > system that Mutt runs on currently). The amount of benefit you'd get > > from this would greatly depend on the nature of the messages stored in > > the folder, though... Folders of moderate size or larger, with mostly > > large messages (or attachments) should see the most benefit, and those > > with many small messages, or with very few messages, would see the > > least (but still some). > > for lseek() to be useful, you need to know where to lseek to > which you wouldn't in this case (if you want reliable parsing). That's easy though, obviously you need to fully parse unread messages, but once they're parsed, you just cache the offsets. You might need to reparse of the thing at the offset you've cached doesn't look like a message (doesn't start with "From ") but otherwise you should be good. > and anyway, i'd like to think mutt uses mmap() for mbox files. I'd like to think that too, but it doesn't. ;-) Or at least, my recollection is that it doesn't. I brought this up in the (distant) past, and IIRC the response was that too many systems had a broken mmap and that it could be underperforming file I/O for other reasons. Which sounded like a crock to me, but I let it go at that, since I didn't want to rewrite the mbox code. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpdkyyMe15L3.pgp Description: PGP signature
Re: header_cache for mbox
On 15.07.2015, Will Yardley wrote: > Did you time the load with header caching disabled as well? No, in fact I didn't. > I've found that opening an uncached folder, or a folder where the cache > is very out of date, sometimes can take a bit longer (while the cache is > being built, presumably), but loading it again tends to be faster. I'll recompile without hcache and report back.
Re: header_cache for mbox
On Wed, Jul 15, 2015 at 10:51:32PM +0200, Heinz Diehl wrote: > On 15.07.2015, Ian Zimmerman wrote: > > > > I'm using both IMAP and maildir, and hcache is a real and quite > > > noticeable improvement. > > > FWIW, I use maildir too but locally, and turning hcache on did not > > result in a clear speed up. My largest folders are around 5000 messages > > each. > > I have mailboxes from ~1000 up to 20.000 emails and the hcache speedup > is clearly noticeable with all of them. I just deleted the cache file > and compared the speed of the first mailbox read to the cached > one. It's a huge improvement. Did you time the load with header caching disabled as well? I've found that opening an uncached folder, or a folder where the cache is very out of date, sometimes can take a bit longer (while the cache is being built, presumably), but loading it again tends to be faster. w
Re: header_cache for mbox
On 15.07.2015, Ian Zimmerman wrote: > > I'm using both IMAP and maildir, and hcache is a real and quite > > noticeable improvement. > FWIW, I use maildir too but locally, and turning hcache on did not > result in a clear speed up. My largest folders are around 5000 messages > each. I have mailboxes from ~1000 up to 20.000 emails and the hcache speedup is clearly noticeable with all of them. I just deleted the cache file and compared the speed of the first mailbox read to the cached one. It's a huge improvement. Btw: which hcache backend do you use? I'm using GDBM, and hcache is really extremly fast.
Re: header_cache for mbox
Derek Martin wrote: > On Tue, Jul 14, 2015 at 08:23:25PM +0200, Heinz Diehl wrote: > > On 14.07.2015, Kevin J. McCarthy wrote: > > > With mbox, I guess the designers thought there wouldn't be that much of a > > > speed improvement > > > because it's just a sequential read of a single file. > > > > That sounds reasonable. > > Except, as far as I can tell, it isn't. I see no reason hcache could > not significantly speed up scanning mbox folders as well, at least on > any system that supports lseek() or similar (which I imagine is any > system that Mutt runs on currently). The amount of benefit you'd get > from this would greatly depend on the nature of the messages stored in > the folder, though... Folders of moderate size or larger, with mostly > large messages (or attachments) should see the most benefit, and those > with many small messages, or with very few messages, would see the > least (but still some). for lseek() to be useful, you need to know where to lseek to which you wouldn't in this case (if you want reliable parsing). and anyway, i'd like to think mutt uses mmap() for mbox files. cheers, raf
Re: header_cache for mbox
While we're at it: is it at all possible (vanilla or patched) to enable hcache for _some_ mailboxes but not for others? The documentation explains that it is possible to force separate hcache database files for distinct mailboxes, so this doesn't look like a huge stretch. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: header_cache for mbox
On 14Jul2015 12:36, Ian Zimmerman wrote: On 2015-07-14 20:23 +0200, Heinz Diehl wrote: I'm using both IMAP and maildir, and hcache is a real and quite noticeable improvement. FWIW, I use maildir too but locally, and turning hcache on did not result in a clear speed up. My largest folders are around 5000 messages each. I use local Maildirs (and local mboxes). hcache makes an _enormous_ speedup for opening large Maildirs. I'd expect that hcache on an mbox is far less useful because if an mbox changes size or mtime you pretty much have to scan the entire thing to find out what may have changed. With POP, IMAP, Maildir you can scan for new and deleted items cheaply, allowing one to get almost everything from the cache and only do an incremental access to the Maildir or mail server. Cheers, Cameron Simpson Footnotes that extend to a second page are an abject failure of design. - Bringhurst, _The Elements of Typographic Style_
Re: header_cache for mbox
On Tuesday 14 Jul 2015 20:36:05 Ian Zimmerman wrote: > On 2015-07-14 20:23 +0200, Heinz Diehl wrote: > > I'm using both IMAP and maildir, and hcache is a real and quite > > noticeable improvement. > > FWIW, I use maildir too but locally, and turning hcache on did not > result in a clear speed up. My largest folders are around 5000 messages > each. Hmm ... I have tried to set header_cache on by specifying the path: set header_cache = /var/tmp/.mutt/gmail/header_cache BUT, It takes up to 55 seconds or more to sync the cache everytime I login on my gmail account, downloading 5.4MB of data each time. I have in excess of 125k messages and do not want to download all of these locally. Other smaller IMAP4 accounts are much faster. Is this how it should be, or am I doing something wrong? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: header_cache for mbox
On 2015-07-14 20:23 +0200, Heinz Diehl wrote: > I'm using both IMAP and maildir, and hcache is a real and quite > noticeable improvement. FWIW, I use maildir too but locally, and turning hcache on did not result in a clear speed up. My largest folders are around 5000 messages each. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: header_cache for mbox
On Tue, Jul 14, 2015 at 08:23:25PM +0200, Heinz Diehl wrote: > On 14.07.2015, Kevin J. McCarthy wrote: > > With mbox, I guess the designers thought there wouldn't be that much of a > > speed improvement > > because it's just a sequential read of a single file. > > That sounds reasonable. Except, as far as I can tell, it isn't. I see no reason hcache could not significantly speed up scanning mbox folders as well, at least on any system that supports lseek() or similar (which I imagine is any system that Mutt runs on currently). The amount of benefit you'd get from this would greatly depend on the nature of the messages stored in the folder, though... Folders of moderate size or larger, with mostly large messages (or attachments) should see the most benefit, and those with many small messages, or with very few messages, would see the least (but still some). -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpej_axS7hnD.pgp Description: PGP signature
Re: header_cache for mbox
On 14.07.2015, Kevin J. McCarthy wrote: > I think the hcache helps to alleviate network latency (pop/imap) and for > opening and closing thousands of files (maildir/mh). Jepp! And for IMAP, it may not be neccessary at all to read more than the header of most of the mails. Ex: a large mailing list. All headers get cached, making it a breeze to scroll through thousands of mails. Then, only those mails really being read will be fetched. I'm using both IMAP and maildir, and hcache is a real and quite noticeable improvement. > With mbox, I guess the designers thought there wouldn't be that much of a > speed improvement > because it's just a sequential read of a single file. That sounds reasonable.
Re: header_cache for mbox
[14/07 12:59] Jon LaBadie: On Tue, Jul 14, 2015 at 05:29:23PM +0100, Larry Hynes wrote: [14/07 12:42] Eric Smith: >It works for me consistantly with imap and with maildir. >Faster and the files in the header_cache dir are uopdated. >Nope on both counts with mbox. > >What is the reason for this? From the manual: "Mutt provides optional support for caching message headers for the following types of folders: IMAP, POP, Maildir and MH." mbox is not mentioned, presumably because caching of message headers is not supported for the mbox format? I'm confused. mbox is a storage format. POP is a message transfer protocol. I use POP to transfer from an mbox file on the server to an mbox file on my desktop. Is caching supported because I use POP or not supported because I use mbox? Well, there lies a quandary for the ages. The wiki doesn't mention POP as a "folder format", so presumably it is an impostor at the feet of which you may lay your confusion. The wiki does, however, provide one more small clue for the OP... "If you happend (sic) to choose either MH or Maildir, you can improve performance by using header caching..." http://dev.mutt.org/trac/wiki/FolderFormat
Re: header_cache for mbox
On Tue, Jul 14, 2015 at 05:29:23PM +0100, Larry Hynes wrote: > [14/07 12:42] Eric Smith: > > >I have the same compile flags, however I opted for the hcache backend as > >tokyocabinet. > >Even with GDBM, I could not implement header caching on mbox :( > >In fact I thought at one time it was working with mbox as the loading was > >apparently faster than without the > >header_cache set in config. But I could not reproduce it. > > > >So is this indeed supported for mbox? > > > >It works for me consistantly with imap and with maildir. > >Faster and the files in the header_cache dir are uopdated. > >Nope on both counts with mbox. > > > >What is the reason for this? > > From the manual: "Mutt provides optional support for caching message headers > for the following types of folders: IMAP, POP, Maildir and MH." mbox is not > mentioned, presumably because caching of message headers is not supported for > the mbox format? > I'm confused. mbox is a storage format. POP is a message transfer protocol. I use POP to transfer from an mbox file on the server to an mbox file on my desktop. Is caching supported because I use POP or not supported because I use mbox? jl -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: header_cache for mbox
[14/07 12:42] Eric Smith: I have the same compile flags, however I opted for the hcache backend as tokyocabinet. Even with GDBM, I could not implement header caching on mbox :( In fact I thought at one time it was working with mbox as the loading was apparently faster than without the header_cache set in config. But I could not reproduce it. So is this indeed supported for mbox? It works for me consistantly with imap and with maildir. Faster and the files in the header_cache dir are uopdated. Nope on both counts with mbox. What is the reason for this? From the manual: "Mutt provides optional support for caching message headers for the following types of folders: IMAP, POP, Maildir and MH." mbox is not mentioned, presumably because caching of message headers is not supported for the mbox format? Eric ~ % mutt -v Mutt 1.5.23 (2014-03-12) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 3.19.0-22-generic (i686) ncurses: ncurses 5.9.20140712 (compiled with 5.9) libidn: 1.28 (compiled with 1.28) hcache backend: tokyocabinet 1.4.48 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.9/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.2-5ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-w error --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.9.2 (Ubuntu 4.9.2-5ubuntu1) Configure options: '--prefix=/usr' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' '--with-mailpath=/var/mail' '--disable-dependency-tracking' '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'i686-linux-gnu' '--enable-nntp' 'build_alias=i686-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm' Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_NNTP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. misc/am-maintainer-mode.patch features/ifdef.patch Patrick Shanahan wrote on Mon-13-Jul 15 9:10PM * Heinz Diehl [07-13-15 14:42]: > On 13.07.2015, Patrick Shanahan wrote: > > > * Eric Smith [07-13-15 09:17]: > >
Re: header_cache for mbox
Eric Smith wrote: > So is this indeed supported for mbox? Sorry, hcache is only implemented for pop, imap, maildir, and mh. > What is the reason for this? I think the hcache helps to alleviate network latency (pop/imap) and for opening and closing thousands of files (maildir/mh). With mbox, I guess the designers thought there wouldn't be that much of a speed improvement because it's just a sequential read of a single file. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA http://www.8t8.us/configs/gpg-key-transition-statement.txt signature.asc Description: PGP signature
Re: header_cache for mbox
I have the same compile flags, however I opted for the hcache backend as tokyocabinet. Even with GDBM, I could not implement header caching on mbox :( In fact I thought at one time it was working with mbox as the loading was apparently faster than without the header_cache set in config. But I could not reproduce it. So is this indeed supported for mbox? It works for me consistantly with imap and with maildir. Faster and the files in the header_cache dir are uopdated. Nope on both counts with mbox. What is the reason for this? Eric ~ % mutt -v Mutt 1.5.23 (2014-03-12) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 3.19.0-22-generic (i686) ncurses: ncurses 5.9.20140712 (compiled with 5.9) libidn: 1.28 (compiled with 1.28) hcache backend: tokyocabinet 1.4.48 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.9/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.2-5ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.9.2 (Ubuntu 4.9.2-5ubuntu1) Configure options: '--prefix=/usr' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' '--with-mailpath=/var/mail' '--disable-dependency-tracking' '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'i686-linux-gnu' '--enable-nntp' 'build_alias=i686-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm' Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_NNTP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. misc/am-maintainer-mode.patch features/ifdef.patch Patrick Shanahan wrote on Mon-13-Jul 15 9:10PM > * Heinz Diehl [07-13-15 14:42]: > > On 13.07.2015, Patrick Shanahan wrote: > > > > > * Eric Smith [07-13-15 09:17]: > > > > Has anyone implemented this or is considering to do so? > > > > > Been using it for *quite* a few years now. > > > > AFAIK, mutt's header cache only works for IMAP and Maildir, but not > > for the mbox format. >
Re: header_cache for mbox
* Heinz Diehl [07-13-15 14:42]: > On 13.07.2015, Patrick Shanahan wrote: > > > * Eric Smith [07-13-15 09:17]: > > > Has anyone implemented this or is considering to do so? > > > Been using it for *quite* a few years now. > > AFAIK, mutt's header cache only works for IMAP and Maildir, but not > for the mbox format. Guess more research is warranted. I have used mbox for > 10 years and header_cache since implementation on openSUSE. :~ > mutt -v Mutt 1.5.23 (2014-03-12) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 3.11.10-29-desktop (x86_64) ncurses: ncurses 5.9.20130805 (compiled with 5.9) libidn: 1.25 (compiled with 1.25) hcache backend: GDBM version 1.10. 13/11/2011 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.8 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux) Configure options: 'x86_64-suse-linux' '--prefix=/usr' '--datadir=/usr/share' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--with-docdir=/usr/share/doc/packages/mutt' '--enable-imap' '--enable-pop' '--enable-pgp' '--enable-gpgme' '--enable-nfs-fix' '--enable-mailtool' '--enable-compressed' '--disable-external-dotlock' '--with-ssl=/usr' '--with-sasl=/usr' '--with-gss=/usr' '--with-gnutls=/usr' '--with-curses=/usr' '--with-regex' '--enable-smtp' '--enable-hcache' '--with-idn' 'build_alias=x86_64-suse-linux' 'host_alias=x86_64-suse-linux' 'target_alias=x86_64-suse-linux' 'CC=gcc' 'CFLAGS=-Wall -fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -I. -D_GNU_SOURCE -fno-strict-aliasing -fPIE -g3 -pipe' 'LDFLAGS=-Wl,--as-needed -Wl,-O2 -Wl,--hash-size=8599 -pie' Compilation CFLAGS: -Wall -pedantic -Wno-long-long -Wall -fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -I. -D_GNU_SOURCE -fno-strict-aliasing -fPIE -g3 -pipe Compile options: -DOMAIN -DEBUG -HOMESPOOL -USE_SETGID +USE_DOTLOCK -DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP +USE_SSL_OPENSSL -USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO -HAVE_REGCOMP +USE_GNU_REGEX +COMPRESSED +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS +SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE ISPELL="/usr/bin/ispell" SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" -MIXMASTER To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. patch-1.5.3.vk.pgp_verbose_mime patch-1.5.9.aw.listreply.1 patch-1.5.23.sidebar.20140412.txt rr.compressed But you didn't say what distro/version/compile options in your environment, so your version of mutt may indeed not support mbox header caching. Mine does. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net
Re: header_cache for mbox
On 13.07.2015, Patrick Shanahan wrote: > * Eric Smith [07-13-15 09:17]: > > Has anyone implemented this or is considering to do so? > Been using it for *quite* a few years now. AFAIK, mutt's header cache only works for IMAP and Maildir, but not for the mbox format.
Re: header_cache for mbox
* Eric Smith [07-13-15 09:17]: > Has anyone implemented this or is considering to do so? Been using it for *quite* a few years now. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net
header_cache for mbox
Has anyone implemented this or is considering to do so? -- Eric Smith
Re: header_cache compiled and enabled, but no caching
On Thu, Apr 19, 2012, Cameron Simpson wrote: > | The size of > | ~/.mutt_cache remains 0 as well. > > Very suspect. You _did_ make a directory for the cache, and not a file? > > mkdir ~/.mutt_cache No, I didn't. Thanks, this solved the problem! -- Eric Patton
Re: header_cache compiled and enabled, but no caching
On 18Apr2012 13:40, Eric Patton wrote: | On Wed, Apr 18, 2012, Patrice Levesque wrote: | > > set header_cache=/home/epatton/.mutt_cache/ | > > (File permissions set to 666.) | > | > Shouldn't that be 777? | > | | I just tried chmoding my .mutt_cache to 777, and exiting and re-starting | Mutt to no avail - headers are still being downloaded anew. Well, they will the first time if the cache is empty. | The size of | ~/.mutt_cache remains 0 as well. Very suspect. You _did_ make a directory for the cache, and not a file? mkdir ~/.mutt_cache What does: ls -ld ~/.mutt_cache ls -la ~/.mutt_cache show? -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ No, Sir. I don't think its safe to look at the speedometer when I'm going that fast. - Tom Coradeschi
Re: header_cache compiled and enabled, but no caching
On 18Apr2012 12:28, Patrice Levesque wrote: | > set header_cache=/home/epatton/.mutt_cache/ | > (File permissions set to 666.) | | Shouldn't that be 777? Whatever for? It only needs to be writable by the user, being a directory, 700 or 750 o 755 perhaps. Admittedly 666 (or 600 etc - anything not including the 'x' (search) bit) will break things, as a directory needs search permission for you to access files within it. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ No real plot, some good special effects, but not enough to save this very forgettable film. S&N: Windows 95. - Phil Herring on _Mission Impossible_
Re: header_cache compiled and enabled, but no caching
On Wed, Apr 18, 2012 at 12:40:09PM -0300, Eric Patton wrote: > I have compiled Mutt 1.5.21 using '--enable-hcache', and mutt -v shows > it is indeed enabled: [snip] > My header_cache is also defined in my muttrc: > > set header_cache=/home/epatton/.mutt_cache/ > (File permissions set to 666.) > > Despite this, the mail headers get read from scratch upon each Mutt > startup. Are you sure? How do you know? You didn't describe the symptoms you're seeing... it's possible that whatever you're seeing (I assume it's slowness opening mailboxes) is caused by something else. Did you try running with debugging enabled, and did you review the debug log? Is there anything in your cache directory? Did you try removing the cache and restarting Mutt? -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpXfbirtYh9p.pgp Description: PGP signature
Re: header_cache compiled and enabled, but no caching
On Wed, Apr 18, 2012, Patrice Levesque wrote: > > > > set header_cache=/home/epatton/.mutt_cache/ > > (File permissions set to 666.) > > Shouldn't that be 777? > I just tried chmoding my .mutt_cache to 777, and exiting and re-starting Mutt to no avail - headers are still being downloaded anew. The size of ~/.mutt_cache remains 0 as well. ~ Eric
Re: header_cache compiled and enabled, but no caching
> set header_cache=/home/epatton/.mutt_cache/ > (File permissions set to 666.) Shouldn't that be 777? -- --|-- | Patrice Levesque http://ptaff.ca/ mutt.wa...@ptaff.ca | --|-- -- signature.asc Description: Digital signature
header_cache compiled and enabled, but no caching
I'm having trouble heaでer cahcing from my work IMAP server. I have compiled Mutt 1.5.21 using '--enable-hcache', and mutt -v shows it is indeed enabled: >mutt -v Mutt 1.5.21 (2010-09-15) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 3.2.0-2-amd64 (x86_64) ncurses: ncurses 5.9.20110404 (compiled with 5.9) libidn: 1.23 (compiled with 1.23) hcache backend: tokyocabinet 1.4.37 Compile options: -DOMAIN -DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK -USE_POP +USE_IMAP +USE_SMTP +USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL -USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/local/share/mutt" SYSCONFDIR="/usr/local/etc" EXECSHELL="/bin/sh" -MIXMASTER To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. My header_cache is also defined in my muttrc: set header_cache=/home/epatton/.mutt_cache/ (File permissions set to 666.) Despite this, the mail headers get read from scratch upon each Mutt startup. Not sure what else I'm missing here. Everything else in Mutt is fine. ~ Eric.
set header_cache broke sorting
Hi, i have been using mutt for quite some time on a maildir. my inbox is sorted with "set sort=date-received" which worked nicely until i used "set header_cache" to speed up starting up mutt a bit. now my inbox is no longer sorted by the date on which the mails were received. is this a bug or is there something wrong in my config? regards, markus -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: mutt not reading header_cache during startup.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Saturday, September 19 at 10:33 PM, quoth Manish Katiyar: >I can see a big cached file created, but after it >finishes downloading my 80K mails, it says "Error opening mailbox". If >I start mutt again it again starts downloading headers rather than >reading from the cache. For whatever reason, Gmail doesn't like it when people attempt to pull down lots of headers (which is precisely what mutt does). So, after a certain number (I don't know how many), it simply refuses to continue and sends a response saying, essentially, "your command has failed". Now, mutt can handle this several different ways. The way mutt currently handles it is by assuming that failed commands cannot be trusted even a little bit, so any headers transferred by the failed command are considered "unlikely to be accurate", and are thus ignored. I think you can make a valid argument that this isn't good behavior on mutt's part (as such, take it up with mutt-dev), but it seems to me that this is simply an attempt to work around yet more gmail IMAP idiocy (see the list archives for all the various issues people have with gmail's truly awful IMAP implementation). :( ~Kyle - -- It only takes 20 years for a liberal to become a conservative without changing a single idea. -- Robert Anton Wilson -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIVAwUBSrYf2yuveozR/AWeAQiY+w/8CrQztIXq/Yxe2v4WuUF6qNmIpGCgxepz zGh0ckly8meHs6S4yjyz062w2JpjWyoEAF2vbUxHmJ5TzHPHKoMK18Hwq4GdYX6D tMsq4aEQXFr8ZhAT/N5m5rQ6P3nQDKwnqaTRhGDwqsSCY9UDm3Xyzz0LHyOzNVKZ BiT2KgXjmbenmpnJmISCD9p3zVfQ5CqFFu37eewlJ9JIy/rWYdyOwYagw/3TVfxX q2PwGDDQtfg11WzvviEBu62UCAcXGrgOHgqcS5WBRwyWG/tA6NFkd9Obo/QZxsvt lBzQ9avxtq0Q5Hqe0oQ89tyMh57LtzEcEsVVYVjbnngTogux6gE5vD2COrIzW87q y3BZa8Z/o7UssMVzK/Chx2GBoMDhGxTi5tZB8rJT5G6szm7cQnjOs/MqGiS1JRnr qDcm402d4jsPWiexFYejvmSSMCYuSi1tA4XhNuqQZBfxBFZbFSPRUxpu0weLbCxP ccTFQqQ9TLuAAdLXypxzvyxR/LY0Y9zbLugf6IHYd571y7UUAnI9+jdQzu4f6NJp S9lDXTJ13w5Jfych0SIaxglLJO+aksOIl48OhjMbi2TaJ6+28wKS6Vm+D/g98etr 9xGIUb2R7AsGUc+CZ4doB+VZWwjOzU1YwbtCcPEg1V/awutAji3GlqFaVq6lME5e TwnY9M2Cw9I= =6LQN -END PGP SIGNATURE-
mutt not reading header_cache during startup.
Hi, I am trying mutt for the first time to configure with gmail imap. I am unable to make mutt use header caching and after trying for 1 full day with different options decided to send this mail. My muttrc is quite simple. I can see a big cached file created, but after it finishes downloading my 80K mails, it says "Error opening mailbox". If I start mutt again it again starts downloading headers rather than reading from the cache. Relevant details are below. I have also uploaded the mutt debug file http://mkatiyar.110mb.com/muttdebug.tar.gz . Appreciate any help. I am on ubuntu jaunty (kernel 2.6.30), with / on ext3 /home/mkatiyar> cat .muttrc set imap_user = "mkati...@gmail.com" set imap_pass = "something_random" set header_cache=~/.mutt/cache/headers/ set message_cachedir=~/.mutt/cache/bodies set sort_aux=reverse-date-received set spoolfile=imaps://mkati...@imap.gmail.com/INBOX /home/mkatiyar/.mutt/cache/headers> ls -lRt .: total 4 drwx-- 2 mkatiyar mkatiyar 4096 2009-09-19 21:09 imaps:mkati...@imap.gmail.com ./imaps:mkati...@imap.gmail.com: total 55268 -rw--- 1 mkatiyar mkatiyar 57263031 2009-09-19 21:42 INBOX.hcache /home/mkatiyar/.mutt/cache/headers/imaps:mkati...@imap.gmail.com> file INBOX.hcache INBOX.hcache: GNU dbm 1.x or ndbm database, little endian /home/mkatiyar> mutt -v Mutt 1.5.18 (2008-05-17) Copyright (C) 1996-2008 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 2.6.31-rc7 (i686) ncurses: ncurses 5.7.20090207 (compiled with 5.7) libidn: 1.10 (compiled with 1.10) hcache backend: GDBM version 1.8.3. 10/15/2002 (built Nov 5 2008 02:36:47) Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP +USE_GSS -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. -- Thanks - Manish
Re: set header_cache - not recognized
On 08/28/09 19:35, Patrick Shanahan wrote: * Joseph [08-28-09 19:31]: Everything was working in previous version, that is mutt-1.5.16 Ok, now I see that you *did* reply on list, but *why* did you send me a direct copy? You know that I read the list or I would never have seen your original post and responded. Other than increasing the amount of needless/worthless traffic on the net, I cannot understand your sending another copy! SOLVED It seems to me I had two version of mutt installed. -- Joseph
Re: set header_cache - not recognized
On 08/28/09 19:06, Patrick Shanahan wrote: * Joseph [08-28-09 18:36]: I just upgraded to mutt-1.5.20 on Gentoo and when starting mutt I gett two errors: Error in /home/joseph/.mutt/format, line 22: header_cache: unknown variable Error in /home/joseph/.mutt/muttrc, line 1: source: errors in /home/joseph/.mutt/format source: errors in /home/joseph/.mutt/muttrc The first line 22 referes to line: set header_cache="~/.mutt_headercache/" it is not recognized, don't know why. is your version of mutt compiled with +USE_HCACHE? to check: mutt -v |grep USE_HCACHE Second one muttrc line 1: source ~/.mutt/format And I believe that this refers to the headercache err, probably your mutt compile does not support it. But you know how to check.. Yes, +USE_HCACHE is compiled IN: mutt -v |grep USE_HCACHE +HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE Everything was working in previous version, that is mutt-1.5.16 -- Joseph
Re: set header_cache - not recognized
* Joseph [08-28-09 18:36]: > I just upgraded to mutt-1.5.20 on Gentoo and when starting mutt I gett two > errors: > > Error in /home/joseph/.mutt/format, line 22: header_cache: unknown variable > Error in /home/joseph/.mutt/muttrc, line 1: source: errors in > /home/joseph/.mutt/format > source: errors in /home/joseph/.mutt/muttrc > > The first line 22 referes to line: > set header_cache="~/.mutt_headercache/" > > it is not recognized, don't know why. is your version of mutt compiled with +USE_HCACHE? to check: mutt -v |grep USE_HCACHE > Second one muttrc line 1: > source ~/.mutt/format > And I believe that this refers to the headercache err, probably your mutt compile does not support it. But you know how to check.. -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org
set header_cache - not recognized
I just upgraded to mutt-1.5.20 on Gentoo and when starting mutt I gett two errors: Error in /home/joseph/.mutt/format, line 22: header_cache: unknown variable Error in /home/joseph/.mutt/muttrc, line 1: source: errors in /home/joseph/.mutt/format source: errors in /home/joseph/.mutt/muttrc The first line 22 referes to line: set header_cache="~/.mutt_headercache/" it is not recognized, don't know why. Second one muttrc line 1: source ~/.mutt/format format file: set mbox_type=Maildir set spoolfile=~/.maildir/inbox # open the mail box upon start-up incoming mails (~/.mail/inbox) set move=no set alias_file="~/.mutt/aliases" #aliases file set pager_context=1 set pager_index_lines=9 #show a mini-index in pager set menu_scroll set pgp_verify_sig=no #dont show pgp in pager set status_on_top #put status line at top set sort=threads#sort by message threads in index set header_cache="~/.mutt_headercache/" #cache header set text_flowed # set format=flowed set pager_format="%-10.10i %[!%a %b %d %R]" set date_format="!%H:%M %a %d %b " set index_format="%4C %Z %d %?X?%X& ? %-15.15n (%?l?%4l&%4c?) %s" set folder_format="%t %N %F %2l %-8.8u %-8.8g %8s %d %f" set delete=yes #delete without prompting set include=yes #quote msg in reply set fast_reply=yes #no prompting on reply set beep=no #no noise set markers=no #no + on wrapped lines set confirmappend=no#no prompt for save to =keep set to_chars=" +TCF"#no L for mail_list set date_format="!%D %R"# include the year (with index_format) set send_charset="iso-8859-1:utf-8" attachments +A */.* attachments -A text/x-vcard attachments -A application/pgp.* attachments -A application/x-pkcs7-.* attachments -A message/external-body attachments +I text/plain attachments -I message/external-body end file- -- Joseph
Re: header_cache database always growing
On Wed, Nov 28, 2007 at 07:16:57PM +0100, Rocco Rutte wrote: > * Michelle Konzack wrote: >> Am 2007-11-21 11:49:13, schrieb Nicolas KOWALSKI: >>> On Wed, Nov 21, 2007 at 09:37:22AM +0100, Rocco Rutte wrote: >>> > * Nicolas KOWALSKI wrote: > >>> >> I have noticed that the headers databases are always growing, even if >>> >> I delete mails. > >>> > Here it's important from where you delete them. When you delete them > >>> within mutt using that header cache, it should remove those entries > >>> (mutt doesn't sync the hcache to changes using other tools). > >>> I delete these mails within mutt. > >> Me too... And it seems to me like a bug... > > Yes, confirmed with qdbm here. I checked and both qdbm as well as gdbm > provide routines to reorganize/optimize the database which seems to work > here (at least for qdbm). I guess the backends keep the allocated space and > don't free them immediately as that's (maybe lots of) additional costs. > > I'll send out a patch to mutt-dev tomorrow since I need to do some testing > on how fast/slow that actually is. Thanks for your reply. BTW, again about hcache handling, when I delete a folder within mutt, the hcache file remains. Should we also consider this a bug ? Thanks, -- Nicolas
Re: header_cache database always growing
Hi, * Michelle Konzack wrote: Am 2007-11-21 11:49:13, schrieb Nicolas KOWALSKI: On Wed, Nov 21, 2007 at 09:37:22AM +0100, Rocco Rutte wrote: > * Nicolas KOWALSKI wrote: >> I have noticed that the headers databases are always growing, even if >> I delete mails. > Here it's important from where you delete them. When you delete them > within mutt using that header cache, it should remove those entries > (mutt doesn't sync the hcache to changes using other tools). I delete these mails within mutt. Me too... And it seems to me like a bug... Yes, confirmed with qdbm here. I checked and both qdbm as well as gdbm provide routines to reorganize/optimize the database which seems to work here (at least for qdbm). I guess the backends keep the allocated space and don't free them immediately as that's (maybe lots of) additional costs. I'll send out a patch to mutt-dev tomorrow since I need to do some testing on how fast/slow that actually is. Rocco
Re: header_cache database always growing
Am 2007-11-21 11:49:13, schrieb Nicolas KOWALSKI: > On Wed, Nov 21, 2007 at 09:37:22AM +0100, Rocco Rutte wrote: > > Hi, > > > > * Nicolas KOWALSKI wrote: > > > >> I have noticed that the headers databases are always growing, even if > >> I delete mails. > > > > Here it's important from where you delete them. When you delete them > > within mutt using that header cache, it should remove those entries > > (mutt doesn't sync the hcache to changes using other tools). > > I delete these mails within mutt. Me too... And it seems to me like a bug... Thanks, Greetings and nice Day Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: header_cache database always growing
On Wed, Nov 21, 2007 at 09:37:22AM +0100, Rocco Rutte wrote: > Hi, > > * Nicolas KOWALSKI wrote: > >> I have noticed that the headers databases are always growing, even if >> I delete mails. > > Here it's important from where you delete them. When you delete them > within mutt using that header cache, it should remove those entries > (mutt doesn't sync the hcache to changes using other tools). I delete these mails within mutt. > A workaround could either be to try using qdbm as backend (if your > version supports it) and set header_cache_compress to reduce disk > size. Or you could remove those index files from time to time and have > mutt refetch headers. So, I have to use the latter. My mail store is not so huge, so this will not hurt much. Thanks for your reply, -- Nicolas
Re: header_cache database always growing
Hi, * Nicolas KOWALSKI wrote: I have noticed that the headers databases are always growing, even if I delete mails. Here it's important from where you delete them. When you delete them within mutt using that header cache, it should remove those entries (mutt doesn't sync the hcache to changes using other tools). A workaround could either be to try using qdbm as backend (if your version supports it) and set header_cache_compress to reduce disk size. Or you could remove those index files from time to time and have mutt refetch headers. Rocco
header_cache database always growing
Hello, I am using the header_cache feature, for speeding up access to my imap folders. I defined it in my ~/.muttrc with: set header_cache=~/.hcache The ~/.hcache is a directory. I have noticed that the headers databases are always growing, even if I delete mails. For example, my INBOX currently has only ~230 messages, but the headers database is really huge (INBOX was big, around 7000 mails, but I cleaned it a few weeks ago): $ ls -l .hcache/imap\:[EMAIL PROTECTED]/INBOX.hcache -rw--- 1 niko niko 6463484 2007-11-20 20:10 .hcache/imap:[EMAIL PROTECTED]/INBOX.hcache The database is "GNU dbm 1.x or ndbm database, little endian", as told by "file". Am I missing something in the docs ? Thanks, -- Nicolas
Re: mutt header_cache
On Wed, Feb 21, 2007 at 12:29:01AM +, Matt Richards wrote: > On Tue, Feb 20, 2007 at 01:33:53PM -0600, Kevin Monceaux wrote: > > Matt, > > > > On Tue, Feb 20, 2007 at 11:30:47AM +, Matt Richards wrote: > > > > > I added --with-hcache to the configure args when building mutt and it > > > not accepts the set header_cache in the config file and when i run mutt > > > the header cache file is created, however, the fine size is 0 and never > > > seems to budge from being 0 :( > > > > > > Does anybody know why this might be or have I hit another unexplainable > > > issue lol :/ . > > > > If you're installing from the FreeBSD ports collection you can enable > > Mutt's IMAP header cache by defining the WITH_MUTT_IMAP_HEADER_CACHE > > knob. And, if you want to enable Mutt's Maildir header cache, define > > the WITH_MUTT_MAILDIR_HEADER_CACHE knob. A list of available knobs for > > Mutt can be found in Mutt's port's Makefile. > > > > > Hiya, cheers for the replies > > I built mutt with the imap_header_cache knob and now it has bdb as a > dependency but and i'm getting the same issues than the version I > built myself :( > > ldd says thats mutt is built against qdbm ... > > /usr/local/bin/mutt: > .. > libqdbm.so.14 => /usr/local/lib/libqdbm.so.14 (0x28341000) > .. > > I have been playing and I noticed that if the header cache points to a > directory then files are created when I browse to a new IMAP folder but > these files still remain to be blank. > > I have been looking around and found some pages on imap header cache not > working in a cvs version and it sounds like the same problems that i'm > having. > > I'm going to try building a CVS version and see if that helps. I dont > know why i seem to be getting all these problems, lol > > Oh well, will let you know how it goes, please let me know if anybody > has any other ideas. > > Ok i know what it was now lol, after all this it was just an issue with the freebsd system not being able to lock files over nfs lol I set the hcache location to a file in /tmp and it works fine. lol, now i have another issue to look into but mutt is working well now :) Cheers for all of your help, Matty.
Re: mutt header_cache
On Tue, Feb 20, 2007 at 01:33:53PM -0600, Kevin Monceaux wrote: > Matt, > > On Tue, Feb 20, 2007 at 11:30:47AM +, Matt Richards wrote: > > > I added --with-hcache to the configure args when building mutt and it > > not accepts the set header_cache in the config file and when i run mutt > > the header cache file is created, however, the fine size is 0 and never > > seems to budge from being 0 :( > > > > Does anybody know why this might be or have I hit another unexplainable > > issue lol :/ . > > If you're installing from the FreeBSD ports collection you can enable > Mutt's IMAP header cache by defining the WITH_MUTT_IMAP_HEADER_CACHE > knob. And, if you want to enable Mutt's Maildir header cache, define > the WITH_MUTT_MAILDIR_HEADER_CACHE knob. A list of available knobs for > Mutt can be found in Mutt's port's Makefile. > > Hiya, cheers for the replies I built mutt with the imap_header_cache knob and now it has bdb as a dependency but and i'm getting the same issues than the version I built myself :( ldd says thats mutt is built against qdbm ... /usr/local/bin/mutt: .. libqdbm.so.14 => /usr/local/lib/libqdbm.so.14 (0x28341000) .. I have been playing and I noticed that if the header cache points to a directory then files are created when I browse to a new IMAP folder but these files still remain to be blank. I have been looking around and found some pages on imap header cache not working in a cvs version and it sounds like the same problems that i'm having. I'm going to try building a CVS version and see if that helps. I dont know why i seem to be getting all these problems, lol Oh well, will let you know how it goes, please let me know if anybody has any other ideas. Cheers, Matty.
Re: mutt header_cache
Matt, On Tue, Feb 20, 2007 at 11:30:47AM +, Matt Richards wrote: > I added --with-hcache to the configure args when building mutt and it > not accepts the set header_cache in the config file and when i run mutt > the header cache file is created, however, the fine size is 0 and never > seems to budge from being 0 :( > > Does anybody know why this might be or have I hit another unexplainable > issue lol :/ . If you're installing from the FreeBSD ports collection you can enable Mutt's IMAP header cache by defining the WITH_MUTT_IMAP_HEADER_CACHE knob. And, if you want to enable Mutt's Maildir header cache, define the WITH_MUTT_MAILDIR_HEADER_CACHE knob. A list of available knobs for Mutt can be found in Mutt's port's Makefile. Kevin http://www.RawFedDogs.net http://www.WacoAgilityGroup.org Bruceville, TX Si hoc legere scis nimium eruditionis habes. Longum iter est per praecepta, breve et efficax per exempla!!!
Re: mutt header_cache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, February 20 at 11:30 AM, quoth Matt Richards: > I added --with-hcache to the configure args when building mutt and > it not accepts the set header_cache in the config file and when i > run mutt the header cache file is created, however, the fine size is > 0 and never seems to budge from being 0 :( My guess would be that you don't have any of the usual database libraries that is required for that feature (e.g. gdbm or qdbm). ~Kyle - -- Disobedience, in the eyes of any one who has read history, is man's original virtue. It is through disobedience that progress has been made, through disobedience and through rebellion. -- Oscar Wilde -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFF2zSDBkIOoMqOI14RAvlvAJ9XJ2R7HGTAHRhCk9yBdHqC6c/NWACgqkcG YOtoCIpLWjAmYLDcN3BYT7w= =nuGu -END PGP SIGNATURE-
Re: mutt header_cache
On Tue, Feb 20, 2007 at 03:33:08AM +, Matt Richards wrote: > On Mon, Feb 19, 2007 at 10:29:00PM -0500, Dave Waxman wrote: > > On Feb 20 03:26, Matt Richards wrote: > > > hello, > > > I'm using mutt on a slowish connection that is ok but after a while of > > > switching imap folders it gets a little annoying. So i did a abit of > > > searching and found there was a header_cache setting for mutt so I set > > > this in my .muttrc file and now mutt says its an unknown variable or > > > something on startup. > > > > > > Does anybody know why this is? > > > > You're using, "User-Agent: Mutt/1.4.2.2i" and the header_cache feature > > didn't come into play until 1.5.x if I recall correctly. Upgrade mutt > > to a later version. > > > Humm ok, > Only thing is that might be a little difficult, i seem to have problems > with 1.5 not sending email. > I will try again tho > hello, i have 1.5 running now, i used mutt-devel in freebsd ports and i still have no idea why it wont sent mail if i build it myself lol funny world. I added --with-hcache to the configure args when building mutt and it not accepts the set header_cache in the config file and when i run mutt the header cache file is created, however, the fine size is 0 and never seems to budge from being 0 :( Does anybody know why this might be or have I hit another unexplainable issue lol :/ . Cheers, Matty.
Re: mutt header_cache
On Mon, Feb 19, 2007 at 10:29:00PM -0500, Dave Waxman wrote: > On Feb 20 03:26, Matt Richards wrote: > > hello, > > I'm using mutt on a slowish connection that is ok but after a while of > > switching imap folders it gets a little annoying. So i did a abit of > > searching and found there was a header_cache setting for mutt so I set > > this in my .muttrc file and now mutt says its an unknown variable or > > something on startup. > > > > Does anybody know why this is? > > You're using, "User-Agent: Mutt/1.4.2.2i" and the header_cache feature > didn't come into play until 1.5.x if I recall correctly. Upgrade mutt > to a later version. > Humm ok, Only thing is that might be a little difficult, i seem to have problems with 1.5 not sending email. I will try again tho Cheers, Matty.
Re: mutt header_cache
On Feb 20 03:26, Matt Richards wrote: > hello, > I'm using mutt on a slowish connection that is ok but after a while of > switching imap folders it gets a little annoying. So i did a abit of > searching and found there was a header_cache setting for mutt so I set > this in my .muttrc file and now mutt says its an unknown variable or > something on startup. > > Does anybody know why this is? You're using, "User-Agent: Mutt/1.4.2.2i" and the header_cache feature didn't come into play until 1.5.x if I recall correctly. Upgrade mutt to a later version. -- Dave Waxman [EMAIL PROTECTED] http://waxman.org/ signature.asc Description: Digital signature
mutt header_cache
hello, I'm using mutt on a slowish connection that is ok but after a while of switching imap folders it gets a little annoying. So i did a abit of searching and found there was a header_cache setting for mutt so I set this in my .muttrc file and now mutt says its an unknown variable or something on startup. Does anybody know why this is? Cheers, Matty.
