CID 345291
It's actually a false positive because if an extension (".suffix") exists in filespec, it must also exist in newfilespec since it's a copy, but whatever. It's better form to check.

libarchive apparently cannot be used for in-place modification of (e.g. adding files to) existing archives, so if a bundle already exists, this code would over-write it with a new archive containing just the latest packet. Issue reported by acn (IMZADI) via DOVE-Net.

I could and might create an update_archive() function which extracts and re-creates an archive with additional files, but since I don't have that yet, just disable this for now and always use an external archive utility to create or update bundles (so again, an "Archive" configuration is required in your sbbsecho.ini file, which you most likely already have).

Not sure why, as this utility has been deprecated. :-/

warning: ‘%s’ directive writing up to 4096 bytes into a region of size between 4034 and 4097

When searching descriptions for text, include these new metadata fields in the content to search.

Wouldn't work with the new filebase if you tried to use it anyway. Just noticed while watching the v3.19b new feature video that the [.alt_path] was still listed as a command-line option.

(e.g. type "HELP") to get help on string commands, including sysop
commands. File Transfer related sysop commands *not* available via
this command shell however (there's just the one/main menu, so no
"File menu" context from which to execute string/sysop commands).

For nick (in #synchronet at irc.synchro.net).

Default to 64 characters. Maximum value is 65535 characters, but filenames larger than 64 characters may be problematic (e.g. searching for them, displaying them, security concerns), so only increase with caution. Shorter values are fine, but 0 will just revert back to the default.

Prefixed or trailing white-space characters would be hard to discern without this.

These git diff stats are a bit misleading as a lot of files were removed from the git repo and some 3rd party libraries were added.

As discovered while making the Synchronet v3.18b feature video (https://www.youtube.com/watch?v=_IWzIV0_sZ4), when only a shortened version of a long filename is displayed (e.g. due to 80 column terminal width limitations), trying to download that filename by specifying the filename at the Download File(s) Filespec [All Files]: prompt can be problematic.

For example (as seen in the video), the file "SyncTERM-1.1-setup.exe" is displayed as "SyncTERM.exe" (on an 80-column terminal), yet trying to download "SyncTERM.exe" (or "syncterm.exe") using the 'D'ownload command would fail to find a file with that name (understandably, but frustratingly so).

This change will transform the requested filename-to-load if it is at least 12 characters in length and contains no wildcards (* or ?), to include a filename extending wildcard: "filename.txt" will become "filename*.txt" and "longfilename" will become "longfilename*".

For requested filespecs of NULL (all files) or specs containing wildcards or specs (filenames) less than 12 characters in length, no filespec transform takes place: so trying to list/download "a" doesn't match "apple.txt".

Fix build on arm64

See merge request !131

By extracting with with_path=true, the file_list matching won't match the nested DIZ files.

Previously, extracted files were always overwritten (so that is the "default" for Archive.extract() and mostly what I'm specifying in the C/C++ code by default now), but this caused a problem with DIZ extraction: archives that contained multiple DIZ files (e.g in sub-directories), the last to be extracted would be used. A maximum of 3 DIZs can be extracted, so it would usually be the 3rd DIZ in the archive if there were that many.

Another solution would be to *only* extract DIZ files from the root of the archive and I should look into that as well, but the always-overwrite behavior also seemed to be wrong, so that *also* needed fixing (allow caller to control behavior).

This fixes issue #317, at least for archives where the root DIZ exists *before* any nested DIZ files. I'll have to try and create a purposeful archive to test the other conditions (where the root DIZ would appear *after* the nested DIZ(s)).

properties with a value of null were not being documented

Resolves !ERROR Cannot load font \sbbs\xtrn\war\worlds\alderon\terrain.fnt!

I wanted to use an unordered bullet list, but the CSS tricks are making those not-displayed, so going with ordered (numbered) list for now.