Re: mutt cache sensitivity
* Brendan Cully [07-03-28 18:06:14 -0700] wrote:
It seemed like it might be nice to validate the cache file on fetch if
possible. At first I thought I'd just stat the file and compare its
size with the size stored in the headers, but there doesn't seem to be
an appropriate combination of fields in the header structure to
compute this size. Any ideas?
Still the content could change without the size being changed, too. Even
worse, after an aborted write mutt may get the message truncated to
exactly that size it previously wrote (at least for POP, see my other
mail for the weak standard).
I think we should take a database transaction approach with a tempfile:
open a tempfile, write the file and afterwards rename (i.e. commit) with
blocking all signals.
Ideally, the tempfile resides in the final target directory to avoid
lengthy buffer copies for large messages (e.g. you wait ages for a
50 MB message to download and then some more time of moving it from
tmpdir to cache dir). If the tempfile is not in the target directory, we
may get the same problem again when the user kills mutt during the
tmpdir -> message_cachedir copy.
Having it within the target directory would also ensure that there's
enough space available. Prior to comitting it while writing the
contents we would get an error already and could fall back to the dumb
cache POP and IMAP have besides message_cachedir.