home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The World of Computer Software
/
World_Of_Computer_Software-02-385-Vol-1of3.iso
/
w
/
wfs203.zip
/
WFSBUGS.112
< prev
next >
Wrap
Text File
|
1992-12-02
|
6KB
|
162 lines
This file describes bugs, hints, things reported in WFS release 1.x
======================================================================
Incorrout -- Munged addresses using WFSFORGE NDOS or 4DOS
Description:
When "forging" a request using the sample batch file WFSFORGE.BAT
described in the WFS UG &Ref, some addresses can be munged to
unusable forms. For example: The address "foo%bar.UUCP@frobaz.com"
results in an address: "foo.UUCP@frobaz.com".
This problem was reported using NDOS; 4DOS probably also exhibits
similar behavior.
NDOS uses the token after the '%' character to attempt environment
variable substitution on command line parameters. In the example,
the environment variable "bar" does not exist. The substitution by
NDOS results in a null string. The reply address is then munged
into something unuseable.
Conclusion:
Use double percent signs ("%%bar.UUCP") when forging a request.
4DOS interprets the doubles as "use literal '%'".
No corrective action is planned.
Users should be careful when using the '%' character on the command
line with 4DOS.
6-May-92
======================================================================
Abstract:
Incorrout -- File not found message NOT written on invalid 'wfs.help'
Description:
When "wfs.help" does not point to a file, no message is written the
WFSLOG.
Conclusion:
SendHelp() in reqst.c is changed to report the error.
message.spr is changed to document the message.
Fixed in 1.1.3 and later.
2-May-92.
======================================================================
Abstract:
Incorrout -- Log entry has no program name when WFSREQST is run from uuxqt
Description:
The startup message issued by WFSREQST and written to ADMIN/WFSLOG
does not contain the program name when WFSREQST is invoked by uuxqt.
The program name is present and correct when WFSREQST is invoked
from the MS-DOS command line.
Conclusion:
WFSREQST inappropriately looks for the back-slash ('\') character
when parsing out his own name from the execution time arguments
(argv[0]). Waffle's uuxqt program passes thru EXACTLY what he finds
in the aliases file when invoking wfsreqst. The name is correct
when wfsreqst is run from the command line because DOS fixes it
up....
Fixed in 1.1.3 and later.
1-May-92.
======================================================================
Abstract:
Incorrout -- File not found when duplicate directory paths, different drive
Description:
When a sysop configures his files section, and DIRS file, with
duplicate directory names, different drive specification. See
example:
1 /dir="g:\public" /wfs.acc /access=1
2 /dir="h:\public" /wfs.acc /access=1
Then, if the file requested with the command:
/get /public/foo
does not exist in the path "g:\public", the file is not found. the
search does not continue through the remaining dirs file entries.
rick@tworaven.lonestar.org found this one.
Conclusion:
The program does not work as intended.
FilFind() in fil.c will be changed to continue searching directories
when a file not found occurs, even when directory name matches.
Fixed in 1.1.4 and later.
13-May-92.
======================================================================
Abstract:
Incorrout -- Files uuencoded to one part are not sent
Description:
Small files that get uuencoded to only one part do not get sent.
A residue $$WFUU.UUE file is left in the temporary directory.
UUencode may subsequently hang with a message "overwrite existing
file? Y/N" if uuencodeing another small file before the temporary
directory is purged.
Reported in 1.2.5. The problem did not exist in 1.1.x releases and
earlier. Introduced during development of 1.2.x release.
Conclusion:
Function Sendencoded() in sendf.c has an off by one error.
Fixed in 1.2.6 and later.
16-Sep-92.
======================================================================
Abstract:
Incorrout -- Various error messages, abends, misbehavior from WFSSENDF
Description:
A variety of symptoms including messages in the WFSLOG file, abnormal
terminations, incorrect output have occurred in WFSSENDF. The
symptom does not occur when only a few items are processed from the
queue. The problem is more likely to occur when there are a lot of
items in the queue.
Analysis:
Some code paths in AutoMail processing leave a file handle open when
processing is complete. Processing the next queued item causes
another handle to be opened for that item. When more file handles
are opened than there are file handle slots in MS-DOS's file handle
array, then WFSSENDF detects errors at various points in processing.
The symptoms vary because of exactly when it runs out of file handles
may vary.
The problem escaped me in testing because I run with "files=60" in my
config.sys. This permits a lot of items in the queue before WFSSENDF
runs out of file handles.
Circumvention:
1) Run WFSSENDF after receiving mail every time. This will limit the
queue backlog, but may not solve the problem where many WFS requests
come in in one batch.
2) Set "files=nn" to a large number in your config.sys file. This
fixes some, but is again deffecient as a long term solution.
Conclusion:
WFSSENDF will be changed to ensure that open file handles are closed
when processing queued AutoMail requests.
Fixed: 1.3.0 (not public release). 2.0.0 and later.
19-Sep-92.
======================================================================