Re: [Cscmail-devel] Contributions

[Count Z. <cou...@cy...>]

Ben Burnett was overheard mumbling something about this on 26 Oct 2000 17:57:13
PDT

> CountZero,
> 
> I have made a few changes (kludges?) to my version of cscmail 1.6.1 to
> fix a few issues listed below.	I was wondering if my changes would be
> appreciated, and if so what would be the most ideal way (read easy on
> maintainers to incorporate) for me to submit them?  I'm willing to learn
> how to convert my code to your standards/format.
> 
> issues:
> 
> 1. New mail sound is played before duplicate check occurs.
> Visible symptoms:
> -New mail sound is played previous to any duplicate checking any time a
> pop3 account is checked that has any mail.
>	for conditions and solution see issue 3 below.
> 
> 2. New mail sound is played once for each account that has new mail.
>	for conditions and solution see issue 3 below.
> 
> 3. CSCget cannot finish checking mail when sound device is busy.
> 
> Visible symptoms:
> -status dialog freezes when checking for new mail.
> OR
> -error dialog pops up saying "cscget already running" seemingly out of
> nowhere.
> 
> Conditions:
>	-cscmail is configured to check multiple email accounts.
>	-The option to play a sound when new mail is recieved is enabled
> to use a command that doesn't share resources gracefully.
> 
> Process:
> The three issues above are all related to the fact that cscget attempts
> to run the user defined PlaySound command once for each account being
> checked immediately upon finding ANY mail in the account (lines: 173,
> 274).  If the device needed by the PlaySound command is busy cscget just
> waits for it, and can't finish fetching mail.  I fixed this by adding a
> master counter of new messages that only gets incremented each time a
> message passes the duplicate checking done on the TOP of the message. 
> This counter get's checked just before cscget exits and the sound command
> is attempted only once.  At this point cscget still freezes if the sound
> device is busy, so I am passing "&" as the last argument to the &system
> call that issues the sound command.  this releases cscget from the sound
> command which poses a serious memory leak as these commands will just
> pile up until they all either time out if they're smart, or until the
> sound device is free at which point they all go off in succession...	But
> I'm working on that : )
> (you may still hear the new mail sound at strange times unless you fix
> the following issue.)
> 
> 4. Large emails always saved under default account.
> 
> Visible symptoms:
> -When replying to a large email the account used to send the email will
> always be the default account, or account with id 1.
>	Occurs when you:
>	-Reply to the large email saved under the wrong account id.
>	And cscmail is configured:
>	-You have more than one account set up.
> 
> -New mail sound is played but no new mail is downloaded.
>	Occurs when you:
>	-check for new mail on an account from which a large email has
> been previously downloaded and NOT deleted.
>	And cscmail is configured:
>	-Check for dupes is ON and delete files from server is OFF for
> the account being checked.
>	-Check dupes accross all accounts  is OFF under main options.
>	-The pop3 server supports TOP file header checking.
> (this is how I noticed this problem and it was only noticable when you
> have applied my solution to the previous sound issues.	Otherwise you
> ALWAYS hear the new mail sound when checking a pop3 under these
> conditions with mail of ANY size still on the server.)
> 
> Process:
> When downloading large files from a POP3 server cscget saves the email to
> a mbox and enters &import_from_mbox (line 375) to retrieve it.	This is
> done without passing the $account hashref.  &import_from_mbox then
> initializes a new $account hashref based on the default account (lines
> 546-551).  This may not be the account that was originally checked.  This
> $account hashref is then passed to &read_from_mbox (line 558) where it is
> passed to &save_message (line 490).  The result is a message saved in the
> database with an erroneous account id.	Interestingly this message does
> not get saved again even though the dupe check done on the TOP of the
> message says it isn't a duplicate (remember we're only looking for
> duplicates in the same account).  This is because when it is downloaded
> again cscmail attempts to save it in the same wrong account but checks to
> see if it is a duplicate first. (csclib.pl line 358)
> 
> Solution:
> I passed the $account hashref into &import_from_mbox in cscget line 375. 
> This resulted in another argument being added to &import_from_mbox.  I
> added some housekeeping lines to make it default to its previous
> behaviour if this argument isn't passed.  I haven't noticed any ill
> effects of this so far.
> 
> 
> I apologize if any of these issues have been addressed in the 1.7.9
> release.  I couldn't find a list of the known issues.  Or who's working
> on what.
> 
> Thanks,
> 
> -Ben

Wow! This looks great... I had wondered why some mail seemed to get dumped into
the default account instead of going where it belonged.  I must admit that I
did not write the "large mail" code, nor the "play sound" code... Of course,
the developers who DID write that code are now writing Pronto!

I do not use the Play sound feature, so I was not aware of it's bugs... I had
noticed the "default account" issue, but had not traced it to large messages,
and have been too busy recently to hunt this down.  Personally, I think CSCMail
needs a re-write, and I am quite happy to no longer have "co-developers" with
CVS write access... A ton of "features" got added to CSCMail without proper
review.  I have left this alone as I planned on simply writing a C version of
CSCMail from scratch anyway....  (This was a few months ago)

Now, I feel that 1.7.x needs a cleanup and a solid 1.8.0 release prior to me
focusing on the C version... One can see this "shift" in focus by tracking my
CVS commits and work on 1.7.9 in my spare time... The C version has been put on
hold till I get a 1.8.0 release out the door.  1.8.0 is to be simply a "bug
free" perl version... Not a re-write.  I really appreciate you bringing these
issues to my attention, and if you are up to checking out 1.7.9 and seeing if
they still exist (certainly the "large message" bug does... I am not sure about
the sound issues) I would very much appreciate a unified diff that fixes these
bugs in 1.7.9 ... If you do not feel so inclined, I understand, and your bug
report is complete enough to allow me to fix the 1.7.x code myself... 

As far as a list of "known issues" the mailing list archives serve as that, and
for who's working on what? its all me...  There are no other developers of
CSCMail anymore....

I do appreciate and accept and encourage diffs/patches/bug reports etc... but I
have decided that I don't want to deal with the political nightmare that is
involved with a multi-developer project, so CSCMail will continue to be slowly
hacked out by "yours truely"

I am very interested in squashing whatever bugs remain in 1.7.x so that I can
get a stellar 1.8.0 release out the door... This will then free me to work on
1.9.x (aka the C version)

Any help, comments, patches, criticism, bug reports, etc. that can help me get
a nice clean 1.8.0 released are very very very much appreciated...

Thank you for your help!

-Count Zero