Re: Balsa 1.4.1 libmutt bug + patch



Ok, sorry to reply to my own message.  I have been looking aroung at mH 
stuff a bit more and have found a few things.

First, my last email stated that fetchmail does not update the 
.mh_sequences file, when in actuality, it is procmail that is responsible 
for this, not fetchmail. Sorry for the error.

Procmail has lots of questions archived in their mailing list about this 
issue, and they have taken the position that they will not write the 
.mh_sequences file, mostly because mh has not file locking and the could 
clobber the .mh_sequences file while trying to right. Instead, they 
suggest using the mh utility, rcvstore, to do this instead.  Balsa could 
have an option to run this program to deliver mh mail. Another problem 
with the mh_sequences is that the "unseen" sequence that balsa uses is 
user-configurable and is actually set in a file ~/.mh_profile.  So, balsa 
my be interfereing with other mh programs when it writes its mail (using 
the wrong sequence).

All of these issues will probably cause me to move my mH folders over to 
maildir, but before I do, I think it is important that balsa and asmail 
handle these mail folders properly.

julian


On 2003.01.07 17:21 Julian M Catchen wrote:
> Carlos,
> 
> I have done a little more poking around in the balsa source and found 
> that the .mh_sequences file is used properly, with 1.4.2, if you flag a 
> message, or explicitly mark it as unread using the GUI.  The problem is 
> that new messages are never marked in the .mh_sequences file, whether 
> you download mail using Balsa's POP functionality or using a program 
> like fetchmail.  The result of this is that Balsa never sees any "new" 
> mail. Everything is assumed to be read.
> 
> Asmail tries to count the number of unread messages by parsing the 
> "Status:" header in each email. I have been looking how to update asmail 
> to use .mh_sequences, but since Balsa never updates this file when new 
> mail arrives, and other programs, like fetchmail, do not update it 
> either, the result is that asmail always displays the wrong number of 
> new mail -- and there is no obvious way to fix it to use .mh_sequences.
> 
> The only options I can see are 1) update Balsa and other programs like 
> fetchmail to properly write .mh_sequences, or 2) have balsa write the 
> "status" header when a message changes (as when it is flagged or read).
> 
> Any thoughts on how to address this problem?
> 
> Thanks,
> 
> julian
> 
> On 2002.12.14 16:24 Carlos Morgado wrote:
>> On Sat, Dec 14, 2002 at 11:02:04AM -0800, Julian M Catchen wrote:
>> > Hmm,
>> >
>> > I did see the mh_sequences stuff in the code, except all of my
>> > .mh_sequences files are of 0 length. Balsa 1.4.1 does not appear to
>> 
>> ok, that would be a bug. in my tests .mh_sequences is used
>> 
>> > actually write the files.  I looked at my old mH directories and I 
>> have
>> 
>> > created new mH directories from within balsa, and in neither case were
>> the
>> > files written.  Plus applicatinos like asmail still read status 
>> headers
>> 
>> 
>> i'll do some thourough tests
>> 
>> as for old apps, I'm looking for some reference as to if Status:
>> is still required. It's a huge performance hit, specialy on networked fs
>> 
>> 
>> --
>> Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey:
>> 0x1FC57F0A
>> http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5
>> 7F0A
>> ^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G
>> _______________________________________________
>> balsa-list mailing list
>> balsa-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/balsa-list
>> 
>> 
> _______________________________________________
> balsa-list mailing list
> balsa-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/balsa-list
> 

-- 
mail : julian @ catchen.org         | ( topeka )
www  : http://catchen.org/topeka/   |  phx, az
sent : Tue Jan 07, 2003 05:54PM PST | 
  And if cynics ridicule freedom, ridicule community...if "hard nosed
  realists" say that profit is the only ideal...just ignore them, and use
  copyleft all the same.
                        -- RMS



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]