[7881] in SIPB bug reports
Re: pine refiling bug
daemon@ATHENA.MIT.EDU (Laura Baldwin)
Fri Nov 23 01:54:39 2001
Date: Fri, 23 Nov 2001 01:54:27 -0500 (EST)
From: Laura Baldwin <boojum@MIT.EDU>
To: Jacob Morzinski <jmorzins@mit.edu>
cc: <bug-sipb@mit.edu>
In-Reply-To: <3BFD806D.8080108@mit.edu>
Message-ID: <Pine.GSO.4.30L.0111230127350.26596-100000@geskekelud.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 22 Nov 2001, Jacob Morzinski wrote:
> 0) Are we both using the same pine? (The sipb locker pine will say
> "Pine 4.30L" in the upper-left corner of the screen.)
I'm using pine-imap from the sipb locker. It says "PINE 4.30L" in the top
left.
(Er, all of my data is from geskekelud, which is a Sparc5. If that's at
all relevant. I can test on other machines on Monday).
>
> 1) Are you doing the same thing I'm doing? Reading your IMAP inbox with
> Pine, and then saving a message into a unix-style mbox folder in AFS?
I'm reading my IMAP mailbox with pine-imap, and hitting "s" to save (well,
really, refile) to either another IMAP folder on the mail server, or to an
mh folder in AFS, or to a mbox folder (mail/inbox, in pine). All three of
these things break the refiled message.
>
> 2) Are you confident that the file "mail-bug-msg-pre" is an accurate
> copy of the message that's on the server?
I don't have the original of this particular message, having accidentally
broken it due to more refiling tests. I got it off the server using inc
-notruncate.
However, if I put a copy of this message in ~/Mail/inbox, and then look at
that message using pine-imap, it looks okay. If I refile it to INBOX (the
one on the IMAP server), it breaks, so it does seem to be still doing the
same thing.
Anyway, it seems to be me, not a general bug. Further experimentation
shows that if I put my .pinerc aside, I don't get this problem. My old
.pinerc is in ~/.pinerc-old. It's commented as having been created by
pine 4.21, and there's a lot of random ordering differences and such, so
seeing the exact changes is hard. Nothing looks obvious as a flag saying
"botch base64 messages on refile: true" but I'll try and narrow down the
culprit.
-Laura
