28 Feb 1995. History prior to release 3.0 is deleted. ===================================================================== Abstract: Incorrout -- Organization: (null) in message header of digest mailing lists Reported: 3.x Description: For several message header statements in digest mailing lists the operand is "(null)". These header statements include "References:", "Organization:", "Date:". Conclusion: This is broken. There should be no "References:" statement at all. The "Date:" statement should be the date/time the digest was processed. The "Organization:" should be the 'organ' from the STATIC file. Circumvention: none. Fixed: 3.0.1 Updated: 6-Jul-93 ====================================================================== Abstract: Incorrout -- CHKDSK reports 'lost allocation units' after WFSREQST Reported: 3.x Description: After WFSREQST processes (recieves) a message for a Digest Mailing List, if the SysOp runs the CHKDSK program, then CHKDSK reports a 'lost allocation unit'. WFSREQST performs the receive with no error reported and no other unexpected behavior. The problem exists only for those sites running a Digest Mailing List. The problem is not reported in all environments! In plain MS-DOS (not all environments here too!) the problem does occur. The problem does not occur under Windows and may or may not occur under DesqView. Conclusion: Function RecieveMailListFile() in mls.c does not close the spool file before deleting it. A call to SplClose() will be added before the call to SplRemove() in the path where a Digest Mailing List message is being saved. Note the code path that recieves Mailing List message works correctly; no change is required. Circumvention: Run CHKDSK /F occasionally, depending on the amount of traffic you have for a Digest Mailing List, to clean up the lost allocation units. The amount of space temporarily out of service because of the lost allocation unit is small, about the size of a small 'session transcript' message. Fixed: 3.0.2 Updated: 24-Jul-93 ====================================================================== Abstract: Incorrout -- Subject: line in Mailing List messages have "Re:" added Reported: 3.x Description: The subject: line in messages forwarded to members of a mailing list have an "Re:" added to the subject: line. Conclusion: Function MailServer() in sendf.c inserts the "Re:" between the Subject: string and the subject data from the original message. The insert of the "Re:" will be removed. Circumvention: none. Fixed: 3.1.0 Updated: 29-July-93 ====================================================================== Abstract: Incorrout -- Files $$WFS*.DIG are left in the 'temporary' directory Reported: 3.x Description: WFSSENDF, after creating Mailing List digests, leaves the temporary files $$WFSTOC.DIG and $$WFSART.DIG in the directory named in the 'temporary' statement in the STATIC file. Conclusion: The files should be deleted after the digest has been created. Function MakeDigest() in mld.c will be changed to delete the temporary files after creating the digest. Circumvention: Manually, or use a batch file, to delete the temporary files after running WFSSENDF. Fixed: 3.1.0 Updated: 29-Aug-93 ====================================================================== Abstract: Incorrout -- A closed digest's mailing list address is exposed Reported: 3.x Description: The address of a digest mailing list, where the MAILLIST.CFG file has a "ReplyTo:" statement, is disclosed in the body of the mailing list. The spec for RFC1153 says that the To: and Cc: headers are to be included in the message body for each submission to a digest mailing list. WFS's intention to have the list's address visible only to the SysOp when the ReplyTo operand is specified in the MAILLIST.CFG file. This intention flies in the face of the requirement stated in the RFC. By carrying forward the address on the To: or Cc: headers, the mailing list's address is disclosed to readers of the digest. Conclusion: No matter what I do, I'm gonna piss off somebody. So be it. The digestifier will be changed so that if the ReplyTo statement is specified in the MAILLIST.CFG file and the mailing list's alias is found in the To: or Cc: header, then that header will be re-written to obscure the mailing list's address. Some data in the original header statement may be lost. Too bad. Fixed: 3.1.0 Updated: 6-Sep-93. ====================================================================== Abstract: Incorrout -- Boolean expression "token : on" is not parsed Reported: 3.x Description: Boolean terms of the form "token : on" are not recognized in any of WFS's configuration files. A user had coded "join : on" in a MAILLIST.CFG file. The form got the standard Parse error message from the boolean term parser. Conclusion: "On" and "Off" seem to be valid boolean terms. ParBoolean() in par.c will be changed to recognize them. Fixed: 3.1.0 Updated: 6-Sep-93. ====================================================================== Abstract: Incorrout -- Message "Abnormal Program Termination" issued w/o explanation Reported: 3.x Description: When running WFSREQST, as invoked by UUXQT, the message "Abnormal Program Termination" appeared. The results of processing the incomming message appeared to have caused queuing (QD*.2 file) of the commands, but there was no session transcript message queued (in the spool) responding to the incomming request. Conclusion: Function Rmail() in waf.c invokes the RMAIL program using spawnl(). The function checks the return value from spawnl() for '-1' to ensure that the function was able to start the RMAIL program. The function does not check for any other non-zero returns that would indicate an error. In the reported case, the user was running waffle on a 286 box with network drivers, and scads of other TSRs so that the available memory was less than 450K. Waffle ran OK. The support programs ran OK, most of the time. When UUXQT invoked WFSREQST, and WFSREQST subsequently invoked RMAIL, there was not enough memory for RMAIL to run successfully. RMAIL issued the "Abnormal Program Termination" message when he discovered he did not have enough memory to run. Rmail() in waf.c will be changed to check for any non-zero return from RMAIL and report the error when encountered. Fixed: 3.1.0 Updated: 16-Sep-93. ====================================================================== Abstract: Incorrout -- Digest files not deleted when autoDelete specified Reported: 3.x Description: When multiple digest files are created as a result of the digest command only the last minus one digest file is deleted when AutoDelete is 'yes' in the MAILLIST.CFG file. Suppose digest V001N001 exists. Suppose that as a result of digesting articles digests V001N002 and V001N003 are created because a single digest would exceed the DigestSize limit. When the AutoDelete processing occurs, only digest V001N002 will be deleted. This leaves digest V001N001 and V001N003 in the directory. The expected result is to leave only V001N003. Conclusion: Inadequate design. Feh! :-} The digest delete algorithm in Function MakeDigest() in mld.c will be changed to delete the current -1 digest after a new digest has been created and mailed. Fixed: 3.1 Updated: 22-Sep-93. ====================================================================== Incorrout -- Waffle's ADMIN\MAIL file entry says "(null)" Reported: 3.1 Description: Waffle's ADMIN\MAIL file is written to by WFS programs when recieving or sending mail. If the mail item recieved by WFSREQST does not have a properly constructed mail header, having a valid "From " line, then the value for the "From " portion of the ADMIN\MAIL line written by WFSREQST will be "(null)". Conclusion: The reported error occured because a 'Hand Built' mail message was fed to WFSREQST [probably by I/O redirection, as in: "WFSREQST in Waffle and not allowed to in WFS. On testing, this causes WFSFILES to emit an error message about a filename being too long. Conclusion: Function ReadFileInfo() in files.c does not recognize character as a valid separator. The function will be changed to recognize the tab character. Fixed: 3.2.0 Updated: 24-Dec-93 ====================================================================== Abstract: DocError -- REPLYTO user command must be placed before affected commands Reported: 3.1 Description: A user reported that the "replyto" command does not work. He had sent the command sequence: join some-list replyto foo@bar.com The replyto command becomes effective in the command stream where it appears, not for all commands in the stream. Conclusion: The description of the REPLYTO command in USERCMD.SPR will be changed to say that the replyto command only becomes effective for commands following it in the command stream. Note also that the session transcript is mailed to the last specified replyto address in the command stream. This surprised at least one user; that's the way it works. Circumvention: Place the REPLYTO command before any command in the command stream for which you want the replyto to be effective. For the above example, the command stream should be: replyto foo@bar.com join some-list Fixed: 3.2.0 Updated: 25-Mar-94 ====================================================================== Abstract: Incorrout -- No error message written to WFSLOG when invalid wfs.uuencode Reported: 3.1 Description: When the wfs.uuencode static file statement references an invalid path (the drive, directory, or program), WFS does not detect or report the error. Analysis: Code in SendEncoded() checks the return from the system() function call as described in the MS documentation. System() does not report that the referenced program could not be found; it reports only that the command interpreter (command.com) was successfully run or not. In the reported incident, command.com was successfully run, but the uuencode program was not. ... Hence no uuencoded files to send. Further, the path thru SendEncoded() caused the WFSSENDF program to delete the QD* file containing the users request resulting in lost data (Ack!). Conclusion: SendEncoded() will be changed to verify a good path to the UUENCODE program. If the program file is not found, the program will abnormally terminate, preserving the QD* file for the SysOp to deal with. ... Hopefully correct the pathspec error and re-run WFSSENDF. The path thru SendEncoded() will be changed so that errors that cause the requested file not to be sent will abnormally terminate. The intention is to preserve the QD* file and allow the SysOp to correct whatever is wrong without loss of data. Fixed: 3.2.0 Updated: 13-Oct-94 ====================================================================== Abstract: Incorrout -- Message-ID header field is not RFC 1036 compliant Description: RFC 1036 says that the Message-ID: header field is to contain the full domain name of the originating host. Conclusion: Function SplOpen() in spl.c will be changed to use the Waffle node static file variable for data in the Message-ID: header statement. Fixed: 3.2.0 Updated: 14-Oct-94 ====================================================================== Abstract: Message -- Panic: expired Reported: 3.0.x, 3.1.x Description: WFS programs issue a message: "Panic: expired" sometime at the end of January 1995. Conclusion: WFS programs are designed to issue this message, then terminate gracefully sometime at the end of January 1995. Circumvention: Register your use and get an immediate upgrade to release 3.2.0. Release 3.2.0 does not expire. It does, however, have a nasty NagWare message that can be disabled by registering. When you register, you will be given a 'RegisteredKey' that disables the NagWare message. Fixed: 3.2.0 Updated: 27-Jan-95 ====================================================================== Abstract: Doc -- JOIN command syntax: "join [address [comments]]" Reported: 3.2.0 Description: The WFS documentation describes the join command suggesting that [address] is optional. It is. By ommission, the documentation suggests that [comments] may be provided when [address] is ommited. This is not true; [address] is required when [comments] are present. The real problem is that some users confuse WFS command syntax with "listserv" command syntax and attempt to use listserv command syntax on WFS. This apparently does not work. No surprise. What some users want is for WFS's join command to have the same syntax as listserv. Note: I have no personal experience with listserv, and so, did not have a clue as to what was wrong when reports of "bugs" in the join command came in. The command works advertized. ... I guess we call this "cognitive dissonance". The common mail servers: WFS, MajorDomo and listserv all have different command syntax. That's just the way it is. WFS's join command does indeed work, and work correctly, when fed the correct command syntax. Conclusion: Suggestions by an small, but publicly vociferent few users, that want the join command syntax to be changed to something similar to "listserv" cannot be accomodated in the absence of complaints by the many scores of other, apparently satisfied, users. Sorry. When joining a mailing list, if you want to specify comments to be added to the members file, then [address] is required. The documentation will be changed in the ShareWare release of WFS 3.2.0 to emphasize this. In function MlJoin() in mlsr.c, a tighter edit will be applied to [address], if present, to ensure that a "@" or "!" character is present in the address; this will reduce, but not eliminate comments being interpreted as addresses, then being inserted into the members.mbr file, as addresses. If the [address] does not pass the edit, the join command will fail and the help message will be sent to the requestor. ... The SysOp should instruct his users in the help message on the proper syntax for the Join command. Circumvention: Update your 'help' text provided to users to show that if [comments] are desired in the join command, then [address] is required. Also, to help correct errors introduced into the members file, divert commands to WFS into a mailbox file. Then review the messages resulting in funny members file entries and manually update the incorrect members file entries with what was intended by the users. To divert commands into a mailbox file, while continuing to process commands as they arrive, set up the ALIASES file like this: server $$log $$server $$log + c:\user\fileserv\command.log $$server | c:\bin\wfsreqst.exe Fixed: 3.2.xac Updated: 18-Feb-95. ====================================================================== Abstract: Incorrout -- /wfs.deny token in DIRS file not recognized Reported: 3.2.0 Description: The /wfs.deny token in the DIRS file is not recognized. Conclusion: Yup, that's right. There are multiple problems here: 1 -- in dir.c, the /wfs.deny token is found, but the indicator in the dirs structure is not set properly. This causes WFSFILES to list the directory. Function ParseDirsStatement() in dir.c will be changed to set the deny flag in the dir structure on detecting "/wfs.deny". 2 -- in reqst.c the deny indicator is not interrogated on the get command. This causes WFSREQST to queue the file for send. Function FileRequest() in reqst.c will be changed to call DirGetDeny() before honoring the get request. Circumvention: Consider removing the offending entries from your dirs file altogether. RCA: PE, QA In the [complete] re-write of dir.c to reduce memory consumption, the "dir" object was completely extracted from the "fil" object and encapsulated a-la OOP style. ... Complete regression testing of the re-engineered objects was not done. Fixed: 3.2.xaa Updated: 6 Feb 95 ====================================================================== Abstract: Incorrout -- DIRS file error when 'label' field missing from statement Reported: 3.2.0 Description: The Waffle documentation says, and I quote: Entries in the /waffle/system/dirs file may contain a number of parameters, described later in this document. For now, place as the first line in this file: (For DOS systems) 1 /dir="c:/files" /access=1 (For Unix systems) 1 /dir="/u/files" /access=1 Here, the first field (which should be in the first column) is an identifier that will be used with a future version. The /dir= specifies the location where you will store files for that file area, and /access= determines the minimum access level that may enter that file area. ... The dirs file processing algorithms did not allow for users ommiting the 'label' field (the '1' in the example above) and caused "unpredictable" results, usually the directory listing of something you did not want, or nothing. Waffle allows the label field to be ommitted. ... Tom! Shame on you. :-) Conclusion: ParseDirsStatement() in dir.c will be changed to allow for an ommitted label on a dirs file statement. The algorithm will issue a Warning level message and assume a label of "*". Circumvention: Place a label field on each dirs statement. RCA: ID, PE Never assume valid data where a human can screw it up! Fixed: 3.2.xab Updated: 18 Feb 1995. ====================================================================== Abstract: Incorrout -- WFS splash screens emit '19101' for year 2001 Reported: 3.2.0 Description: The WFS splash screen displays the date and time it is run. The date for dates greater than 1999 have a formatting error that displays the year as '19' plus the number of years since 1900. Discovered by a registered user trying to see if WFS 3.2 had an expire-by date in it. ... It does not. Conclusion: Function Udate() in dos.c formats the date incorrectly. The function will be changed to format the date correctly. Circumvention: I won't worry about it for now. You can wait. :-) RCA: PE Fixed: 3.2.xac Updated: 18 Feb 1995. ====================================================================== Abstract: Incorrout -- Unpredictable results when WFS programs multi-task Reported: 3.2.0 Description: Well, somebody had to do it. A user running OS/2 ran Waffle in one dos session. He ran a cron job in another. At midnight Waffle's schedule file said run uuxqt; uuxqt processed a piece of mail directed at WFSREQST. Also, the cron job in the other dos session ran WFSSENDF at the same time. ... All hell broke loose! The symptom experienced is that the temporary file and the spool files got corrupted. There were numerous messages in the WFS logs about deleting temporary files. Ugh! Also, because the queue control file was accessed simultaneously, a "counters reset" message (presumably the counters were reset also) was issued twice. ... Ugh! Multiple other symptoms are possible, depending on the timing. The major objects exposed are: the log file, spool temporary file, temporary work file, the queue control file. Conclusion: WFS programs were not designed to run multitasked. People do it anyway. The best I can do is protect them from themselves. A set of locking functions will be implemented in lock.c. LockGet() will be called just after the waffle static file has been internalized and before the log is opened. LockGet() will get a lock on a temporary file. This means that the WFS programs will have to wait if another WFS program is running. LockRelease() will be called at normal program termination and from Abend(). LockGet() will try for about 30 minutes to get the lock. If he is unable to get the lock, then he will give up and exit gracefully with exit code 3 (the WFS Abend() exit is 1). The assumption is that whoever is holding the lock is hung. Since one of the resources to be protected from concurrent update is the WFSLOG file, the failed attempts to get the lock will not be shown in the log file (the lock is obtained before the log is opened). ... You have to see it on the console to believe that it works. WFS serialization algorithms use Microsoft's runtime library routine _locking() to cause serialization. When WFS programs are run on an operating systems that does not support the _locking() function, ... serialization is ineffective, at best. The serialization function is predicated on multiple instances of WFS programs seeing the same STATIC file variable "temporary". When "temporary" is different between instances, serialization is attempted, but not actually performed. ... You are on your own. Circumvention: Don't run WFS programs multi-tasked. RCA: NR Fixed: 3.2.xae Updated: 2/28/95 ====================================================================== Abstract: Incorrout -- MSG "Info: Waiting for WFS lock" then program termination Reported: 3.3.0 Description: On startup, WFS program issues message "Info: Waiting for WFS lock". The message repeats 200 times VERY QUICKLY then the program terminates. There are conflicting reports on what configurations cause the symptom. On a "vanilla" MS-DOS platform (3.0 and up) without SHARE.EXE loaded, the symptom occurs as described above. With SHARE.EXE loaded (the author's configuration) the problem does not occur. The symptom does NOT occur under Windows, with or without SHARE.EXE loaded. There have been no reports from OS/2 Warp users (that I recall) of any kind. One DesqView user reported that with SHARE.EXE loaded, the box locked up without displaying any messages; another DesqView user reported that without SHARE.EXE loaded, the box locked up. ... What's the truth? I'd go for "DesqView without SHARE.EXE" causes the box to lock up, based on the report of a reliable user. ... Thanks, Jerry. My request for help from DesqView has gone unanswered now for about a week. ... Oh well. Conclusion: WFS 3.3 was not tested under DesqView before release. Apparently, I didn't test with and without share.exe loaded. Code will be changed in LockGet() to detect whether share.exe is loaded. If loaded, it uses the serialization mechanism; when not loaded, the serialization mechanism is not used. SHARE.EXE (or equivalent function, e.g. Windows) is required to be loaded before WFS programs run. Circumvention: Load SHARE.EXE before running WFS programs. When DesqView is used, load SHARE.EXE before starting DesqView. RCA: ID, QA Fixed: 3.3.1 Updated: 23 Mar 1995 ====================================================================== Abstract: Abend -- Abend with message: "Panic: ParseFile(): fopen():..." Reported: 3.2.0 Description: A user reports an Abend and the above message when he selectively runs WFSSENDF with the -F option, later without. Conclusion: When specific queue types are processed, ommiting others, a gap is created in the sequencing of queue record numbers. As designed, WFSSENDF is supposed to not care if there are queue records missing from the sequence. Some maintenance activity removed the "don't care" part of this code. What maintenance activity? Dunno. It is restored now. Circumvention: Don't run WFSSENDF with any exclusion options. RCA: PE, QA Fixed: 3.3.xba Updated: 4/7/95. ======================================================================