https://gitlab.synchro.net/main/sbbs/-/work_items/1278#note_10630
Fixed on master (local commits, not yet pushed):
**Reading bare compressed files.** All libarchive read sites now enable the "raw" format, but accept a raw result only when a decompression filter was applied, so an uncompressed non-archive is still "Unrecognized archive format". A bare `.gz`, `.bz2`, `.xz` or `.zst` file reads as a one-entry archive named after the file minus its compression extension (`log.txt.gz` -> `log.txt`), not the gzip header's optional stored name, which may contain a path. `Archive.list()` decompresses the data to report the size, since libarchive doesn't know it in advance. Tested: list, hashed list, read and extract all match the original data; `.tgz`/`.zip` behave as before.
`filecontents_lib.js` caches "unreadable" verdicts, so `EXTRACTORS` was bumped to 2: `.gz` files previously recorded as unreadable get listed on their next view. Hosts sharing file areas should all run the new build before then, or an older build re-records the failure under the new version. `ARCHIVE_TYPES` there now also includes `xz` and `zst` (it already had `gz` and `bz2`).
**Should `gz` be a valid Supported Archive Format in SCFG?** No. That list is the set of types Synchronet *creates* (QWK/REP packets and temporary download archives), and users can pick any entry as their QWK packet type. Only `zip`, `7z`, `tgz` and `tbz` can be created, and a bare `.gz` holds a single file, so it could never hold a QWK packet. Listing `gz` offered users a packet type that always failed to build. Reading and viewing archives never depended on this list.
SCFG now removes any type that can't be created, tells the sysop which, and saves the cleaned list, so an existing `gz` entry is dropped the next time the field is visited. The help text no longer suggests adding other libarchive formats, and the File Options overview no longer claims the list covers mail attachments and the testable/extractable file types.
No SCFG change is needed to view `.gz` files: with the fix above they list in the web file index and the terminal viewer as-is.
Two older issues found while testing, not changed here: a text file made only of single-word lines (e.g. `seq` output) is claimed by libarchive's mtree reader and fails with "Missing type keyword in mtree specification", compressed or not; and the `Archive.type` getter returns the error string "archive_read_next_header returned 1: (null)" for an archive with no entries instead of null.
_Authored by Claude (Claude Code), on behalf of @rswindell_
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)