This documents all the bugs that have been reported in both PCElm and
PCOak, with explanatory notes and "fixed" status. The lists are
presented first as a one-line summary of each bug, with links to greater
detail further on in the page.
Various people have contributed to this list: for brevity they are referred
to by initials here, but a list matching initials to
names is available. The same initials are used in both the buglist and
wishlist pages.
Bugs are listed by index number; these are sequentially assigned when new
reports are received, so there is no implicit "order" in the list.
In the summary lists below, the "PCElm?" entry indicates whether
this bug was also present in PCElm.
| Index
| Description
|
| Reported
| PCElm?
|
| Verified |
| 021 |
Memory error viewing extremely long messages | |
ST |
Y |
| 022 |
Very long recipient lists may be truncated | |
ST |
Y |
| 048 |
Scrolling back before multipart boundaries can confuse
pager | |
ST |
Y |
| 058 |
Mailbox containing Ctrl-Z gets truncated when
read/rewritten | |
BHK |
Y |
| 059 |
Embedded ASCII 0 (NUL) in messages causes problems | |
ST |
Y |
| 062 |
Missing space before "Date:" timezone cause it to be
missed | |
IF |
- |
| 063 |
Can't run internal DOS commands with "!" shell
command | |
IF |
- |
| 065 |
Running out of disk space while updating mailbox may be
disastrous | |
ST |
Y |
| 066 |
Can't specify spaces in weedout list | |
IF |
Y |
| 067 |
Uuencoded attachments not recognised in MIME messages | |
PD |
Y |
| 068 |
Selection moves up when last message deleted in top->bottom
list | |
DGB |
- |
| 069 |
MIME multipart boundary misparsed from unusual
"Content-Type:" | |
LT |
Y |
| |
| Reported, but unsubstantiated/unrepeatable |
| 013 |
"video 0" (BIOS video) doesn't work | |
PD |
Y |
| 024 |
Keyboard F/f confusion | |
PD |
Y |
| 028 |
Lots of deleting (possibly with saving) causes crashes | |
IR, PD |
? |
| 033 |
Possible error calling program after decoding? | |
PD, MS |
? |
| 064 |
Up arrow from "alternative" prompt can scramble
display | |
IF |
- |
| Index
| Description
|
| Reported
| PCElm?
|
| Fixed in PCOak 0.2 (14 Nov 2003) |
| 053 |
Printing sends spurious character at end of file | |
PD |
Y |
| 054 |
Unnecessary buffer overflow warning with long "Date:"
lines | |
ST, MG |
N |
| 055 |
Message bodies starting with whitespace cause problems | |
MG |
N |
| 056 |
Transmitted text files ending with Ctrl-Z detected as
binary | |
MG |
N |
| 057 |
Subject search pattern initially random | |
PD |
N |
| 060 |
Creating new mailbox when changing doesn't clear message
list | |
PC |
N |
| 061 |
"New mail arrived" check before updating mailbox file is
broken | |
ST |
Y |
| |
| Fixed in PCOak 0.1.1 (10 Apr 2002) |
| 018 |
Failure to display spool file with many large messages | |
LT, PC |
Y |
| 027 |
Prompt box 1 char too narrow for text/html prompts | |
PD, ST |
Y |
| 029 |
Very long header lines break EOH detection | |
IF |
Y |
| 030 |
Always use From for attributions, even if Reply-To comes
first | |
LT |
Y |
| 031 |
Move into all msgs (inc. last) when pressing 'd' in
viewer | |
LT, MS |
Y |
| 032 |
Detect *all* disk write errors and act accordingly | |
MS |
Y |
| 034 |
Raw CR in text confuses pager | |
BHK |
Y |
| 035 |
Multipart boundaries should match fully | |
IF, ST |
Y |
| 036 |
Position cursor correctly on bottom-line prompts | |
ST |
Y |
| 037 |
File handle leak in mailto() | |
PD |
Y |
| 038 |
Pager wrapping can cause quoted-printable display glitch | |
PD |
Y |
| 039 |
Messages with no body are always unread | |
ST |
Y |
| 040 |
Skipping MIME attachments only works in multipart
messages | |
ST |
- |
| 041 |
Only first 255 chars of long header lines get weeded out | |
ST |
Y |
| 042 |
Bogus address shown in index if mail from you has no
"To:" | |
ST |
Y |
| 043 |
First message overruns if mailbox doesn't start with
"From " | |
ST |
Y |
| 044 |
Help screen not drawn correctly in BIOS video mode | |
ST |
Y |
| 045 |
Insert mode: original cursor not restored on shell/exit | |
IF |
- |
| 046 |
Removal of own address from group replies is case
sensitive | |
ST |
Y |
| 047 |
Aborting 'c'hange to non-existent mailbox may corrupt
index | |
PD |
Y |
| 049 |
Header line with no space after ':' is ignored | |
ST |
Y |
| 050 |
Own address not removed from group reply if
"To: me ,a1 ,a2" | |
ST |
N |
| 051 |
Problems sending messages/files which don't end with
newline | |
ST |
N |
| 052 |
Display not updated after deleting 1 tagged but unselected
msg | |
ST |
Y |
| |
| Fixed in PCOak 0.1 (17 May 2001) |
| 017 |
Shelling to DOS broken (low memory, I guess) | |
PD |
Y |
| 025 |
Screen display sometimes unusable after normal exit | |
ST, PD |
Y |
| 026 |
Bad save filename/path causes pager error | |
PDa, BHK, MS |
Y |
| |
| Fixed in PCOak 0.0.9 (20 Oct 2000) |
| 001 |
Corrupted mailbox/folder when sorted by date | |
BHK, PC |
Y |
| 002 |
Current folder gets corrupted when new message saved into
it | |
ST, PC |
Y |
| 003 |
Crashes on long Subject: lines | |
PC |
Y |
| 004 |
Crashes with long To: and Cc: lines | |
PC, ST, CK |
Y |
| 007 |
Broken Group replies | |
TW |
Y |
| 008 |
Saving reply mail when username contains space | |
MS, CK |
Y |
| 009 |
Broken RFC-822 address handling in outgoing mail | |
ST, NJ, MS |
Y |
| 010 |
Off-by-one wrapping of long header lines | |
ST |
Y |
| 011 |
Case-sensitive domain name comparisons on sent mail | |
ST |
Y |
| 012 |
Quoting long text lines doesn't split the line | |
ST |
Y |
| 015 |
"saveall 3" filenames broken | |
PD |
Y |
| 016 |
Article scrolling broken? | |
PD |
Y |
| 019 |
MIME attachment names not always picked up | |
PC, MS, BHK |
Y |
| 020 |
MIME decoding failures | |
BHK, NJ |
Y |
| 023 |
Lower case month names get sorted wrongly | |
MS |
Y |
| |
| Fixed in PCElm 1.12 beta 4 (10 Jan 2000) |
| 000 |
PCElm 1.12 "about" corruption | |
JW |
Y |
| 005 |
Problems saving sent mail with "." in name | |
PC |
Y |
| 006 |
Failed saving of multiple recipients | |
??? |
Y |
| |
| False alarms |
| 014 |
Help prompts always on | |
PD |
Y |
-
021: Memory error viewing extremely long messages (ST)
- If a message being viewed with the internal pager has more than 13000
lines, it can cause a memory allocation error; this may crash the program.
This bug will disappear when the internal pager gets its forthcoming
rewrite
-
022: Very long recipient lists may be truncated (ST)
- Although the buffer overrun code in PCOak should prevent crashes when
dealing with very long recipient lists, they may be truncated; this is not
good enough.
The cause of this bug is known; it will be fixed when the internal
handling of recipient lists is rewritten to use linked lists instead of
fixed-length arrays
-
048: Scrolling back before multipart boundaries can confuse pager (ST)
- Using the up-arrow key to scroll back before a multipart boundary line
leaves the pager believing it's already seen the boundary, although the
current position is now back before the boundary again; this can confuse
things badly when it sees the boundary again as you scroll back down!
This bug will disappear when the internal pager gets its forthcoming
rewrite
-
058: Mailbox containing Ctrl-Z gets truncated when read/rewritten (BHK)
- A long-standing problem with PCElm and PCOak (in common with many other
DOS programs); the mailbox and folder files are read in "text" mode,
which means that any Ctrl-Z characters are taken to mean end-of-file. Ctrl-Z
is a perfectly legitimate character in SMTP mail, albeit one which users of
Demon's KA9Q and its offshoots are unlikely to see (because Ctrl-Z is removed
from incoming text data); but if one does become embedded in a mailbox or
folder, PCElm and PCOak will stop reading at that point. If changes are made,
leading to the original mail file being updated from the version in memory,
anything following the Ctrl-Z in the original file will be lost.
This is obviously a serious bug, although it will only affect people
using SMTP servers which preserve Ctrl-Zs in the incoming SMTP data (like
Brian, who has a homebrew SMTP server); it will be fixed when the file
handling rewrite is completed
-
059: Embedded ASCII 0 (NUL) in messages causes problems (ST)
- Although illegal according to the more recent RFC 2822, ASCII
"NUL" (zero) characters are apparently permitted within mail
messages by RFC 822. Such characters in a saved mail message will cause the C
string handling functions used in PCElm and PCOak to produce unexpected
results (the NUL character is the string terminator byte in C), and should
therefore be detected and dealt with when mailboxes and folders are read,
before they can cause problems. Note that KA9Q-based SMTP servers should be
unable to create mail messages containing NUL characters.
This will be fixed when the file handling rewrite is completed
-
062: Missing space before "Date:" timezone cause it to be missed (IF)
- If the space between the time and timezone in the Date line is missing
(e.g. 19:30:48+0000), PCOak will fail to parse the timezone.
While the space should be there (it is required by RFC 2822),
nonetheless it would be nice if PCOak could parse the date correctly even if
it isn't
-
063: Can't run internal DOS commands with "!" shell command (IF)
- Internal DOS commands (e.g. DIR, DATE etc.) cannot be
run from PCOak's "!" shell command; this is due to a limitation in
the swapping exec() code used by PCOak.
Pete has come up with a straightforward workaround for this, which will
be implemented shortly
-
065: Running out of disk space while updating mailbox may be disastrous (ST)
- PCOak 0.1.1 detects and reports write errors caused by running out of
disk space, which prevents many of the problems associated with PCElm's
failure to check anything. However, when overwriting a file, the space used
by the old file is not freed by DOS until the new version of the file has been
written and closed; this means that if PCOak updates an original mail file
from its local copy, and runs out of disk space while overwriting the file,
the update will fail and there is potential for data to be lost.
It would probably be best if, before copying or updating the original
mail file, PCOak checked that there was sufficient free space on the disk in
question and warned the user if there isn't enough
-
066: Can't specify spaces in weedout list (IF)
- An old PCElm bug, which incredibly hasn't been noticed before now: if
you want to include a space in a "weedout" list (in which entries
are separated by whitespace), e.g. to weed out the start-of-header lines which
begin "From ", it is obviously intended that you can
use an escape (\32) in place of the space, and this is what the
sample PCELM.RC files have always contained; however this doesn't work, and
never has done - the entry From\32 has the same effect as
From, and weeds out both "From " and
"From:" header lines.
This should be a fairly easy fix, and will be in the next version
-
067: Uuencoded attachments not recognised in MIME messages (PD)
- An old PCElm bug/mis-feature: scanning for uuencoded attachments in the
message body is disabled if it's a MIME message. At face value this doesn't
seem unreasonable; but Turnpike, at least, will create MIME messages
with uuencoded attachments in the message body.
Scanning for uuencoded attachments should be done even if it is a MIME
message (or perhaps made optional)
-
068: Selection moves up when last message deleted in top->bottom list (DGB)
- Introduced in 0.1.1: if the "next message" selection moves
down the screen rather than up, automatic next-message selection moves up from
the last message in the list instead of staying on the last message.
This should be an easy fix
-
069: MIME multipart boundary misparsed from unusual "Content-Type:" (LT)
- Another old PCElm bug, which got replicated when redoing the code for
PCOak: MIME "Content-type:" header field containing a multipart
boundary which isn't enclosed in quotes, and is immediately followed by a
semicolon and another parameter, causes the boundary string to be incorrectly
parsed; PCOak never sees that incorrect boundary string, and therefore doesn't
display the message body at all.
This should be a fairly easy fix
-
018: Failure to display spool file with many large messages (LT, PC)
- Sometimes, PCElm will load the mail file (USER.TXT), but will fail in
one of the following ways: generally, the mail list page will show no
messages (ie blank list), or, less often, the list of mail will appear
but any attempt to read a message will be ignored. In neither case does
the machine crash, and leaving PCElm as normal gives normal operation.
The big problem with PCElm and early PCOak was memory fragmentation with
the constant reallocation of an array holding pointers to the message
structures; PCOak 0.1.1 now uses a linked list of structures which avoids the
memory fragmentation, and is therefore able to load a much larger number of
messages before (inevitably for a DOS program) running out of memory.
Moreover, running out of memory is now handled gracefully, and memory is no
longer "lost" when this happens
-
027: Prompt box 1 char too narrow for text/html prompts (PD, ST)
- ... concerns the sizing of the pop-up message boxes, where the width of
the box is too narrow [if the MIME type is too small, e.g. text/html].
Now fixed
-
029: Very long header lines break EOH detection (IF)
- Ive just come across an instance where PcTree has inserted the message
read header in an inappropriate place. The message had very many addresses and
very little content. The header was put in the middle of these and UNREAD
couldnt find it.
PCOak 0.1.1's handling of very long lines is considerably improved, and
it should no longer get confused by them
-
030: Always use From for attributions, even if Reply-To comes first (LT)
- in some cases, a quoted reply will be attributed to the Reply-To
address rather than the sender (frequently happnes on mailing lists).
Now fixed
-
031: Move into all msgs (inc. last) when pressing 'd' in viewer (LT, MS)
- When reading messages one after the other by hitting
"D"(elete), the last message is ignored; deleteing the penultimate
message returns you to the listing with the last mesage highlighted ready for
processing.
Now fixed
-
032: Detect *all* disk write errors and act accordingly (MS)
- I recently extracted a Word document to a fullish disc; the extraction
process proceeded without error messages, and I ended up with a file with
extension .DOC, as expected. However, it didn't work; it had been truncated to
fit in the space available.
All file writing operations are now checked for problems, and
errors are reported
-
034: Raw CR in text confuses pager (BHK)
- The two embedded CR characters are indeed the cause of the problem; I
suspect you're right about the Mac editing. PCOak doesn't check for raw CR
characters...
Control characters in the message body (whether raw or encoded by
quoted-printable) should now be handled correctly in the pager; raw CR is now
treated as an LF
-
035: Multipart boundaries should match fully (IF, ST)
- Neither PCElm nor PCOak checks for MIME multipart boundaries giving an
exact match, but rely on RFC 2046's assurance that you only need to match the
initial characters; this isn't good enough in the Real World.
Now fixed
-
036: Position cursor correctly on bottom-line prompts (ST)
- Prompts on the bottom line in the viewer, e.g. multipart prompts, don't
get the cursor at the end of the line, because the "window" isn't
full-screen (the display has fewer lines than usual); they stay on the last
line instead.
Now fixed
-
037: File handle leak in mailto() (PD)
- When forwarding nore than one message, PCElm and older versions of
PCOak would lose track of all but the last opened file, and could run out of
file handles as a result.
Now fixed
-
038: Pager wrapping can cause quoted-printable display glitch (PD)
- Pager line wrapping at a quoted-printable encoded character would occur
correctly, but the start position for the next line was not always set back to
the start of the "=XX" encoded character sequence, resulting in a
display of one or more hex digits rather than the decoded character.
Now fixed
-
039: Messages with no body are always unread (ST)
- When rewriting a changed mailbox file, the "Status: R"
line is written at the end of the header; if there was no blank line
separating this message from its body, the end of header was not detected and
the Status header line not written.
End of header should now be correctly detected no matter what
-
040: Skipping MIME attachments only works in multipart messages (ST)
- The attachment skipping ability added to PCOak used to search for a
multipart boundary, which didn't work if the attachment was the entire message
body, rather than a multipart body part.
Once realised, this was an easy fix
-
041: Only first 255 chars of long header lines get weeded out (ST)
- Header lines over 255 characters long, which should be weeded out, are
only hidden for the first 255 characters: everything after that is displayed
normally.
The header weeding system assumed that all lines would fit into the
fixed-length 256-byte buffer it read them into; lines over 255 characters long
confused it, and the remaining bits of the line didn't always get weeded out.
The entire weeding system has been rewritten for 0.1.1, and it no longer gets
confused by long header lines
-
042: Bogus address shown in index if mail from you has no "To:" (ST)
- Silly bug in PCElm (continued into early PCOak); mail send by you uses
the "To:" header field to display on the indexs screen, but its
search for a "To:" field would run on past the end of the message if
it couldn't find one, leading to a display of either garbage or the
"To:" line from a different message!
Now fixed; if a "To:" line cannot be found, it falls back to
using your full name
-
043: First message overruns if mailbox doesn't start with "From " (ST)
- The length of the message was calculated from the beginning of the
file, even though the message itself didn't start there; displaying the
message would start at the right place but use the wrong length, with
predictably silly results.
Nox fixed
-
044: Help screen not drawn correctly in BIOS video mode (ST)
- Highlighted characters in BIOS mode video are drawn by a function which
sets the attribute correctly for the highlighted character, but used to reset
it incorrectly afterwards, leading to problems for the text following the
highlighted character.
Now fixed
-
045: Insert mode: original cursor not restored on shell/exit (IF)
- The first version of Pete Disdale's new insert-capable line editor
used to change the cursor size to indicate insert mode, but didn't always
reset it back afterwards; this was never really an active bug, except for Ian
who used a special version of PCOak provided by Pete, containing his new
code.
The final implementation of Pete's inserting line editor in PCOak 0.1.1
is much more careful about restoring cursor sizes when not in the line
editor
-
046: Removal of own address from group replies is case sensitive (ST)
- Old PCElm bug, accidentally carried over into early PCOak: removal of
your own address from group replies uses a case-sensitive comparison, so
user@domain gets removed, but User@domain doesn't.
Now fixed
-
047: Aborting 'c'hange to non-existent mailbox may corrupt index (PD)
- If you deleted one or more messages from a mailbox/folder, then tried
to change to a non-existent mailbox/folder, rejected the opportunity to create
it and ended up back in the original folder (which in the meantime had been
saved to disk and was therefore now shorter than it had been), the current
selection index wasn't updated to reflect the reduced number of messages; if
the selection bar had been near or at the last message in the list, this would
cause considerable confusion in the index screen display.
An easy fix, once tracked down
-
049: Header line with no space after ':' is ignored (ST)
- PCElm, and early PCOak, used to insist on there being a colon and a
space immediately after a header field name, and would fail to identify the
header field if the space was not present; this requirement has no basis in
the RFCs, which are happy for there to be no space after the colon. While
rare, some mail has been seen with a "Cc:address" line, which wasn't
honoured while doing a group reply.
The requirement for a space after the colon has been removed
-
050: Own address not removed from group reply if "To: me ,a1 ,a2" (ST)
- The new address parsing code introduced in PCOak 0.0.9 had problems
matching simple user@host addresses if one of them ended with space followed
by a comma.
Now fixed
-
051: Problems sending messages/files which don't end with newline (ST)
- Message bodies, or transmitted text files, which don't end with newline
caused problems: (a) the TXT file doesn't end with newline, which may cause
problems for KA9Q; (b) the saved copy doesn't end with newline, which means
the Start-Of-Header line for the next message in the folder isn't seen; (c) if
encoded with quoted-printable, the last line of the message is missed off
completely! This one was unique to PCOak; PCElm's erroneous assumption that
it always obtained a complete line when reading text files, while it caused
many problems, actually insulated it from files which didn't end with a
newline!
Text attachments or messages which don't end with newline now get a
newline added to them within PCOak, which avoids the problem
-
052: Display not updated after deleting 1 tagged but unselected msg (ST)
- A rather nasty bug in PCElm and early PCOak: if you tag a single
message, move the selection bar away from the message and then then press 'd'
to delete it, the display is not updated for that message: it is still shown
as tagged and undeleted, even though its status has actually been changed to
untagged and deleted. The true status is only revealed if you move the
selection bar past the message, or cause the whole index display to be
redrawn. The same thing happens with undeleting.
Now fixed
-
001: Corrupted mailbox/folder when sorted by date (BHK, PC)
- Folders can get corrupted (with duplication of messages) when
maintained in chronological order.
This is almost certainly the same bug as 002 below:
BHK's memories of it are somewhat vague, as it happened to him some years
ago
-
002: Current folder gets corrupted when new message saved into it (ST, PC)
- New mail being saved to the currently-viewed folder (e.g. sending mail
while viewing SENT) sounds an alert, and then rewrites the folder with
disastrous consequences (e.g. duplication of messages).
This was the same bug as (somewhat differently) reported by PC; it is
almost certainly the same as BHK "Corrupted mailbox/folder when sorted by
date" bug (001) above. It occurred when the current
mailbox was altered and its contents reread from disk, if it was displayed
sorted by date or reversed; PCElm lost track of the last message in its
internal list, with mayhem ensuing when the mailbox was finally rewritten to
disk
-
003: Crashes on long Subject: lines (PC)
- Long subject lines cause crashes
Buffer overrun fixes mean this no longer causes a crash; the over-long
Subject line will simply be truncated
-
004: Crashes with long To: and Cc: lines (PC, ST, CK)
- Long To: or Cc: addresses can crash the program, especially when trying
to reply ('R' or 'r').
Buffer overrun fixes mean this no longer causes a crash; however long
address lists in a group reply may end up truncated (see bug 022)
-
007: Broken Group replies (TW)
- PcElm often seems to screw up the addresses in a group reply. And as a
default a group reply shouldn't include yourself.
See 009 below; additionally, the full address of the
user is removed from the recipient list, not just the SMTP address itself
-
008: Saving reply mail when username contains space (MS, CK)
- Replies to some mail items (depending on the From: line) can produce an
"unable to save" message, and may produce invalid DOS filenames. CK
observes that this happens when sending a message to two addresses on the same
system; the attempt to save a second copy fails, even though the message is
queued correctly. MS also notes that when sending mail To:
abc@xyz.com,def@xyx.com,ghi@xyz.com the message "unable to save file to
\DEMON\SPOOL\MAIL\, " is briefly displayed.
Some of this should was fixed in PCElm 1.12; additionally, PCOak has a
more robust and consistent system for generating DOS filenames from mail
addresses, which should not be capable of generating an invalid filename
-
009: Broken RFC-822 address handling in outgoing mail (ST, NJ, MS)
- Recipient addresses of form user@domain (Full Name) and
Full Name <user@domain> are both handled incorrectly.
Address parsing in PCOak is considerably better than in PCElm;
addresses with full names now work properly
-
010: Off-by-one wrapping of long header lines (ST)
- It folds the To: line at or before 80 characters, but if an address ends
at the 80-char mark, it breaks the line *before* the comma.
Line folding in headers has been overhauled, and now works correctly
-
011: Case-sensitive domain name comparisons on sent mail (ST)
- Domain names on outgoing mail are compared case-sensitively, so that
mail to a@foobar.com, b@FooBar.com will be sent as two separate
messages.
Now fixed
-
012: Quoting long text lines doesn't split the line (ST)
- Long lines, especially q-p, get quote marks ("> ")
inserted at the appropriate points, but it doesn't force a newline before
them!
Long, wrapped quoted-printable lines, when quoted in a reply, are now
broken at the "soft" wrapping points used in the q-p layout; they
each get a quote mark ("> ") at the start of the line
-
015: "saveall 3" filenames broken (PD)
- The "saveall 3" setting in the .rc seems to me to be severely
broken, and to create very strange filenames.
See entry for 008
-
016: Article scrolling broken? (PD)
- Message display can get confused; for example, scrolling backwards
through an article one sometimes finds oneself in another article.
PCElm's internal pager was badly broken, and could quite easily lose
its place in the mailbox file, causing random seeks into other parts of the
file; the position tracking has been rewritten in PCOak
-
019: MIME attachment names not always picked up (PC, MS, BHK)
- (This was originally an enhancement request, but is actually a bug)
Filenames given on the MIME Content-Type line are not always picked up
correctly, leaving the suggested attachment name as OUTPUT.ENC
Only the very first entity header line was being scanned for the
filename! Now all headers are scanned
-
020: MIME decoding failures (BHK, NJ)
- MIME base 64 attachments in a multipart/mixed message sometimes fail to
decode, or produce files that are the wrong size
All entity header lines are now read before decoding; base64 decoding
now decodes to the correct size when file is not a multiple of 3 bytes long
-
023: Lower case month names get sorted wrongly (MS)
- Lower case month names in the Date header cause the message to be sorted
as though it is January.
Silly programming error in PCElm; fixed in PCOak