I'm using web alpine and would like to be able to archive my email messages, but I've been unable to locate this feature. I have noticed that the non-web alpine has this feature. Unfortunately I have moved my web alpine messages to folders which the non-web alpine does not recognize. How would you suggest archiving my web alpine email messages? --tom
At line 2670 of mailpart.c, alpine does a
++(*a);
to move to the next attachment - presumably the child of the
MESSAGE/RFC822 that it is inspecting.
The problem is that if a broken IMAP server returns NULL for the child
body part, and there are no following MIME body parts, this will move to
randomness. This can be reproduced by trying to access the message.
Some code is needed to guard against running off the end of the attachment
list. There is a linked list higher up on the stack ("current") which
properly shows that it is at the end of the list, but this code in
format_msg_att() just assumes that it can move down a vector.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Hi all, First, thank you to the developers for supporting ALPINE and continuing to improve this wonderful software to work with the newest technologies. I moved from Elm to PINE about 15 years ago and stubbornly stuck with it through the GUI craze. I just discovered ALPINE yesterday (where have I been?) -- alias pine='alpine' of course since old habits are hard to break. I did not modify my existing PINE configuration since ALPINE was able to use it. $ alpine -v Alpine 2.00 (LNX 1167 2008-08-23) built Thu Nov 20 20:20:10 CST 2008 on midas $ uname -a Linux archus 2.6.29.1-archus #1 SMP PREEMPT Mon Apr 13 12:37:12 EDT 2009 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux $ cat /etc/slackware-version Slackware 13.0.0.0.0 $ ls -lah mail/ total 3.2G [-----8<-----] -(Continue reading)rw------- 1 jonl users 401M 2010-03-01 09:11 Alert_SonicWall -rw------- 1 jonl users 203M 2010-03-02 12:06 ML_Full-Disclosure -rw------- 1 jonl users 256M 2010-03-02 12:01 ML_SA-Users -rw------- 1 jonl users 140M 2010-03-02 12:01 ML_SELinux [-----8<-----] I have quite a few rules to move mailing list email to the appropriate mailboxes (Berkeley mbox) based on header matching. With PINE 4.64 (and
On Tue, 2 Mar 2010, Jon wrote: > [...] > > I have quite a few rules to move mailing list email to the appropriate > mailboxes (Berkeley mbox) based on header matching. With PINE 4.64 > (and earlier) it would parse my INBOX and move hundreds of messages to > various mailbox files within a couple seconds. With ALPINE 2.00 it > takes 5-10 seconds to move message(s) to each mailbox. It takes > minutes to filter the entire INBOX. > > It's as if PINE 4.64 would simply concatenate the new messages to the > mailbox file whereas ALPINE is opening the entire mailbox. I have not > tracked memory usage during these operations. Yes, that's the gist of the problem. The rationale was to properly implement something to do with message IDs. Mark Crispin has described the issue several times on this list -- I can't recall the specifics off-hand. Possibly relevant search terms: slow folders; message UID. > Is this a bug that can be fixed or can the behaviour be changed back > to the old way using a configuration option? Neither. It's doing something 'more correct', but that correctness comes with a performance penalty. > If not, would switching from the Berkeley mailbox file format to mbx > help? Yes. Not using the ill-defined 'mbox' format is generally the correct(Continue reading)
On Tue, 2 Mar 2010, Benjamin R. Haskell wrote: > On Tue, 2 Mar 2010, Jon wrote: > > > [...] > > > > I have quite a few rules to move mailing list email to the appropriate > > mailboxes (Berkeley mbox) based on header matching. With PINE 4.64 > > (and earlier) it would parse my INBOX and move hundreds of messages to > > various mailbox files within a couple seconds. With ALPINE 2.00 it > > takes 5-10 seconds to move message(s) to each mailbox. It takes > > minutes to filter the entire INBOX. > > > > It's as if PINE 4.64 would simply concatenate the new messages to the > > mailbox file whereas ALPINE is opening the entire mailbox. I have not > > tracked memory usage during these operations. > > Yes, that's the gist of the problem. The rationale was to properly > implement something to do with message IDs. Mark Crispin has described > the issue several times on this list -- I can't recall the specifics > off-hand. Possibly relevant search terms: slow folders; message UID. See in particular Mark's message: Re: [Alpine-info] turn off X-UID scan when appending message to mbox? http://mailman2.u.washington.edu/pipermail/alpine-info/2009-September/002507.html -- -- Best,(Continue reading)
On Tue, 2 Mar 2010, Jon wrote: > I have quite a few rules to move mailing list email to the > appropriate mailboxes (Berkeley mbox) based on header matching. > With PINE 4.64 (and earlier) it would parse my INBOX and move > hundreds of messages to various mailbox files within a couple > seconds. With ALPINE 2.00 it takes 5-10 seconds to move message(s) > to each mailbox. It takes minutes to filter the entire INBOX. I have that problem too. I hope there is/will come a solution to it. Thomas Gramstad
On Tue, 2 Mar 2010, Jon wrote: > I have quite a few rules to move mailing list email to the appropriate > mailboxes (Berkeley mbox) based on header matching. With PINE 4.64 (and > earlier) it would parse my INBOX and move hundreds of messages to various > mailbox files within a couple seconds. With ALPINE 2.00 it takes 5-10 > seconds to move message(s) to each mailbox. It takes minutes to filter > the entire INBOX. > > It's as if PINE 4.64 would simply concatenate the new messages to the > mailbox file whereas ALPINE is opening the entire mailbox. Your guess is mostly accurate. Alpine calls a library routine to do the message copying. That routine does a considerably more work in the newer versions of the library in order to maintain message unique identifiers (UID). Among other things, it requires validating the UIDs of all other messages prior to assigning a new one. mbox format is simply not designed for UID management; and the way that it has to be done is quite a bit clanky. > Is this a bug that can be fixed or can the behaviour be changed back to > the old way using a configuration option? There is an option called "Save Combined Copies" that will improve the performance of saves in all formats, but especially mbox format. If you do not have that option checked, do so. When that option is not checked, each message is saved separately.(Continue reading)
I take issue with one point below. On Tue, 2 Mar 2010, Mark Crispin wrote: [snip] :>Once upon a time, silly people wanted to save messages in a particular :>order in a mailbox to order the index, rather than using the index sort :>functionality. They were very unhappy that multiple saves would instead :>save messages in the order they appear in the source mailbox. Thus, they :>were given a ridiculous save mode that literally saves each message, one :>at a time, opening the destination separately for each message, in order :>to guarantee that order. Worse, and even more ridiculous, that mode is :>the default. :> I want and use this feature. I use it to get a folder into date order (if its got messed up as often happens when saving) since it is tedious to sort4 every time. However I totally agree that the default is backwards. [snip] -- -- Barry Landy Home: +44-1223-570417 192, Gilbert Road College: +44-1223-472134 Cambridge CB4 3PB Efax: +44-870-458-0205 England Email BL10@...
On Tue, 2 Mar 2010, Mark Crispin wrote: :>On Tue, 2 Mar 2010, Barry Landy wrote: :>> I want and use this feature. I use it to get a folder into date order :>> (if its got messed up as often happens when saving) since it is tedious :>> to sort4 every time. However I totally agree that the default is :>> backwards. :> :>If you're talking about arrival sort, a better fix would be simply to :>split arrival sorting into internaldate sorting (which can be done quite :>fast) and mailbox order sorting. No. I am talking about the sort order in folders which I create manually and operate using Save. AFAIK there is no arrival sorting for those. If they get badly out of order I want to get them back into order. :> :>If you never use mailbox order sorting, you won't care how the mailbox :>ends up. :> :>-- Mark -- :> :>http://panda.com/mrc :>Democracy is two wolves and a sheep deciding what to eat for lunch. :>Liberty is a well-armed sheep contesting the vote. :> -- -- Barry Landy Home: +44-1223-570417 192, Gilbert Road College: +44-1223-472134(Continue reading)
On Tue, 2 Mar 2010, Barry Landy wrote: > I want and use this feature. I use it to get a folder into date order > (if its got messed up as often happens when saving) since it is tedious > to sort4 every time. However I totally agree that the default is > backwards. If you're talking about arrival sort, a better fix would be simply to split arrival sorting into internaldate sorting (which can be done quite fast) and mailbox order sorting. If you never use mailbox order sorting, you won't care how the mailbox ends up. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote.
RSS Feed26 | |
|---|---|
25 | |
21 | |
23 | |
8 | |
32 | |
13 | |
34 | |
18 | |
13 | |
17 | |
21 | |
32 | |
19 | |
45 | |
28 | |
48 | |
63 | |
11 | |
118 | |
82 | |
61 | |
43 | |
52 | |
16 | |
49 | |
60 | |
95 | |
20 | |
103 | |
33 | |
12 | |
66 | |
72 | |
104 | |
126 | |
49 | |
93 | |
83 | |
72 | |
32 | |
143 | |
147 | |
48 | |
72 | |
107 | |
82 | |
111 | |
109 | |
101 | |
56 | |
272 | |
152 | |
89 | |
107 | |
95 | |
78 | |
86 | |
108 | |
123 | |
108 | |
209 | |
73 | |
183 | |
133 | |
183 | |
7 |
