On Sunday, 08 April 2007 at 21:53, Kyle Wheeler wrote: > On Saturday, April 7 at 01:29 PM, quoth Brendan Cully: >>> When it detects that the cache is outdated, does it delete it and >>> create a new one, or does it still silently ignore the cache >>> (requiring the user to guess why mutt is suddenly slower)? >> >> Actually I'm a little puzzled by this. In my experience, if the header >> cache check fails, the headers get refetched and replace what was in the >> cache, so that the slowdown only occurs once. Which DB back end are you >> using? > > QDBM, though I must admit, this hasn't happened recently. It used to be a > regular occurrence that suddenly mutt would simply always fetch the headers > of all messages whenever I opened up a folder, and as soon as I realized it > was happening, I would have to delete the hcache and suddenly mutt would > spring to life again. > > This also happened a couple times when I upgraded the library; I assumed > that maybe they'd changed their on-disk format, refused to read in the old > format, and mutt simply fell back to fetching all the headers every time. > > But, like I said, this hasn't happened in a few months; but since I hadn't > seen any relevant entries in the changelog, I assumed that the potential was > still lurking there, and that mutt would refuse to trash it's own > (unreadable) cache. > > If that's been fixed, then that's groovy, and sorry for the noise. It would still happen if the file itself were incompatible with mutt's DB engine. I've tried to fix that in d12143e1a610.
Attachment:
pgpRqaPtf45Bj.pgp
Description: PGP signature