- my @files;
- # XXX some options:
- # a. take message numbers on stdin
- # b. take full paths to messages on stdin
- # c. take standard [msgs] list on command-line
- # d. assume inc has just finished so cur points to start of new mail and
- # just do cur-last
- # Hacked up b. here, but I'm not happy with it. I'm renaming files that
- # stay in inbox for no reason, and leaving gaping holes. Any of the above
- # approaches has those problems, and the solution is always the same:
- # my @filtered;
- # sub store_message {
- # my $msg = shift; # rename $src_msg
- # my $mhfolder = shift;
- # my ($msgnum, $mhmsg); # rename $dst_msg and $dst_msgpath
- # # ...
- # # XXX don't hard-code inbox
- # if ($mhfolder eq 'inbox') {
- # # If @filtered is empty, this message already has the right number.
- # $msgnum = shift(@filtered) || next;
- # $mhmsg = "$mh/$mhfolder/$msgnum";
- # } else {
- # # $msgnum = get_highest_msgnum() and search
- # # XXX don't hard-code unseen
- # mark($mhfolder, $msgnum, 'unseen');
- # }
- # push(@filtered, $msg);
- # rename($msg, $mhmsg);
- # }
-
- # The above guess-code takes into account the problem below.
-
- # XXX I just thought of a problem, but we might be able to get away with it
- # anyway! The problem is when mhpath has more message paths to output than
- # fit in the pipe buffer, it blocks WHILE HOLDING THE SEQUENCE LOCK.
- # If there's a message in there that stays in inbox, minc renames it, and
- # tries to lock the sequence file, and we DEADLOCK. However, if we do
- # nothing with sequences at all for the inbox folder, I think everything
- # just works! inc has added everything to unseen already. If we don't
- # touch it, we have an unseen list that includes a bunch of messages that
- # are gone, and the ones that stayed in inbox are already) included in that
- # list! The next inc (or any other sequence-writing operation) should elide
- # the now-non-existent messages from unseen. It just might work!