Bug fixes for DOWNSORT version 6.3


Bugs in 6.3m and status of version 6.3p
============================================================================

1. Long descriptions appear only partly in INF files after the IPF-output is
   processed by the IPF compiler.

IPFC does not support lines longer than 255 characters, but Downsort 6.3m
does not support word wrapping, regardless what is specified on the IPFlist
parameter.

Status: Corrected.
        - Wrapping for long descriptions added to IPF-lists
        - Default linelength for IPF-lists set to 255.


----------------------------------------------------------------------------

2. Import of File_Id.Diz gives error messages with "%f<CR>"

COMPRESS.CFG is not processed correctly.

Status: Corrected.


----------------------------------------------------------------------------

3. Area groups are not reported in HTM lists

Only areagroups that include a highest level division are reported. If an
areagroup includes only lower level division(s) then these are not always
listed.

Status: Corrected.


----------------------------------------------------------------------------

4. Specified linelength of continuation lines exceeded

Negative indentation values (e.g. -c-16) were incorrectly handled for
continuation lines.

Status: Corrected.


----------------------------------------------------------------------------

5. Filesize and Filedate of CDROM areas appear twice in output

When NOT specifying CDROM NoScan (default), the directories of fileareas on
CDROM are scanned for filesize. But when areas are of type DateList, and the
Files.Bbs contain filesize and filedate (as it should be), these fields were
handled by Downsort as part of the description. Therefore this info appeared
twice in output lists.

Status: Corrected.


----------------------------------------------------------------------------

6. With CDROM NOSCAN files are marked 'offline' after DIZ-import

Under the following rare conditions you may loose filesize and filedate
information and other info in your Files.Bbs entries for CDROM areas:
 - the area is for Maximus defined as TYPE CD DATELIST
 - Downsort.Cfg specifies CDROM NOSCAN
 - Downsort.Cfg has DIZimport active
 - Import of File_Id.Diz from the archive on CDROM is succesful
An importent thing to know and remember is that in Downsort DIZimport has
precedence over CDROM NOSCAN! When import of File-Id.Diz is succesful, its
contents will completely replace the previous file description. This
INCLUDES filesize, date, Maximus download flags and download counter field.
The conditions for this situation are extremely rare for a real life
Bulletin Board, and since a fix is not so simple in the current version of
Downsort, there will be no cure on short term. So better prevent this
accident by letting Downsort scan CDROM directories with DIZimport.
In case it happened to you, and you don't have a backup Files.Bbs anymore
it is possible to repair lost filesize and date fields as follows:
 - comment-out the CDROM specification in Downsort.Cfg
 - optionally nullify DIZimport (since you did that before!)
 - rerun Downsort with only the FILFilePath line as output specification
Unfortunately there is no cure for lost other fields.

Status: Open. Possibly fixed in 6.4


----------------------------------------------------------------------------

7. Total bytecount in list headers far too small.

Overflow of 32-bits bytecounters when having more than 4 GB.

Status: Corrected