https://gitlab.synchro.net/main/sbbs/-/commit/bff68ad04b5051effdd82bb0
Modified Files:
src/sbbs3/filedat.c
Log Message:
Check max_files value in extract_files_from_archive() better

Address issue reported by Nightfox via DOVE-Net:
Today I was using the Archive class to extract exactly one file from a zip file, and I'm a little confused on the exception throwing behavior regarding the max_files parameter. When calling extract(), I gave it a filename pattern and expected exactly 1 file to be extracted, so I also gave a max_files argument as 1. It extracted the one file, but it threw an exception with the error "Error: maximum number of files (1) extracted (after extracting 1 item successfully)".

Should that be an error condition to throw an exception? I expected 1 file to be extracted, and that file was extracted successfully. If I specify max_files as 2, then it doesn't throw an exception.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ef2fa232ddcb2cef11c7458a
Modified Files:
src/sbbs3/filedat.c
Log Message:
If filename_maxlen is 0, don't use it enforce a maximum filename length

This is just extra paranoia now since the reading of file.ini enforces the value range
8 <-> 65535 now.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/9a57677a496ff570f4038cd2
Modified Files:
src/sbbs3/filedat.c
Log Message:
Avoid possible divide-by-zero in gettimetodl()

Default to 100000 (cps) if passed a rate_cps argument value of 0.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/31ded19d6a8e8933b9f999e4
Modified Files:
src/sbbs3/filedat.c
Log Message:
Resolve warning: enumeration value `FILE_SORT_NATURAL' not handled in switch

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e2d3cd89bba7f5556c6245e2
Modified Files:
src/sbbs3/filedat.c
Log Message:
Fixup extract_diz() - fallback to external archivers

The fallback to external extractors/archivers didn't really work unless a libarchive function (called from extract_files_from_archive) actually failed and the return value was < 0. A return value of 0 would mean the external
file extractor would never be used.

This was discovered when trying to import DIZ from old ZIP files (from 1992) that used "Implode" compression method for the FILE_ID.DIZ, which is a compression method *not* supported by libarchive. This is a reason why sysops might want to leave Info-zip's 'unzip' as a configured Extractable File Type handler (in SCFG) for 'zip' files.

Don't call the external archiver 3 times for the 3 DIZ filenames supported. Just call the external archiver once, and pass all 3 filesnames. This also means that the call to system() can return non-zero (e.g. Info-zip 'unzip'
will return 2 if any of the files aren't present in the archive, even if
one is) - so ignore this return value from system(). This speeds up bulk
import (e.g. using addfiles.js).

Unfortunately, I couldn't really find a nice cross-platform way to suppress
the unzip "caution: filename not matched" message sent to stderr. That's
a bummer and a little annoying.

Ignore 0-length DIZ files.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/50b4ff0a10cf4efacb49ab0e
Modified Files:
src/sbbs3/filedat.c
Log Message:
Replace line-feeds with space in extended descriptions used for short desc

Fixes cosmetic/readability issue when imported DIZ files that have line/word wrapped text and the space between words was being removed.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net