Hi, * 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.
bye, Rocco -- :wq!