On Thursday, 29 March 2007 at 12:33, Rocco Rutte wrote: > Hi, > 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. I'll add a bcache_move operation and create the tempfile as id.tmp, then rename it to id. rename should be atomic, so there's no need for signal handling, and if we use a fixed name, the natural result is that it'll simply get overwritten and renamed the next time the user attempts to fetch the message.
Attachment:
pgprYSluBbq1x.pgp
Description: PGP signature