more notes about inc support

diff --git a/minc b/minc
index 301cf35..7e6ed2f 100755 (executable)
--- a/minc
+++ b/minc
@@ -871,17 +871,44 @@ if (!caller()) {
     # 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:
-    # # Keep track of the message numbers we've renamed out of inbox
     # my @filtered;
-    # for (@msgs) {
-    #     if (!my $new = filter($_)) {
+    # sub store_message {
+    #     my $msg = shift;
+    #     my $mhfolder = shift;
+    #     my $mhmsg;
+    #     # ...
+    #     # XXX don't hard-code inbox
+    #     if ($mhfolder eq 'inbox') {
     #         # If @filtered is empty, this message already has the right number.
-    #         $new = shift(@filtered) || next;
+    #         $mhmsg = shift(@filtered) || next;
+    #     } else {
+    #         # $mhmsg =  get_highest_msgnum() and search
+    #         # XXX Holy crap, there's an ancient bug here!  I call mark on
+    #         # $msgnum instead of $mhmsg!  I bet the retry when message number is
+    #         # claimed has never actually executed; after all, I've never refiled
+    #         # messages or anything while minc was running; until this week, it
+    #         # wasn't safe since I wasn't locking!
+    #         # XXX don't hard-code unseen
+    #         mark($mhfolder, $mhmsg, 'unseen');
     #     }
-    #     push(@filtered, $_);
-    #     rename($_, $new);
+    #     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!
+
     if (@ARGV > 0) {
         # XXX if sticking with this approach, reject arg other than '-'
         chomp(@files = <>);