Per FMail.txt:
Area name
          This is the name of the conference. It can be up to 50
          characters long. This name is often referred to as the
          area tag.

I did not locate a FidoNet spec to contradict that and support a 35 character maximum area tag length. I think Mystic also has a 50 character area tag limit. So 50 character area tags are fine I guess.

So up to 50 characters are now supported in SBBSecho and SCFG for area tags (for message and file echoes). The exception is the (new to 3.19) optional area tag stored in msgs.cnf/file.cnf is limited to 40 characters due to reserved space limitations. If you need a tag stored per sub (most sysops do not) and it needs to be longer than 40 chars, use the newsgroup name instead (limited to 63 chars).

Changed at the request of Keyop via IRC.

A name ending in a symbol (e.g. "Erich B.") would cause problems with this matching logic.

Midnight Commander (mc) apparently sends requests like this for files
(e.g. aliases) in the virtual root directory.

Fixes another part of the reported issue #288.

ftpalias() can return true even when the directory is not set to a valid
directory index (i.e. set to -1), so using as an array index would definitely
segfault. Part of commit 8ad30b6c by Deuce 3 years ago.

I didn't test this as I'm not sure exactly the combination of ftpalias.cfg
content and FTP command received that would trigger this, but it's most
definitely a bug.

So should fix the segfault reported in issue #288.

Since users can (and usually do) display extended descriptions in their normal file listings anyway, it makes sense to go ahead and search them for the text (e.g. with the 'F' command from the default command shell File menu/prompt). So the "search/display extended info" prompt has been changed to just "Display extended file info" since it no longer controls whether or not the extended description is searched for the text (it always is). The FL_EXFIND was renamed to FL_EXT and only controls whether the extended info is display (the FL_FIND mode flag, always renamed, must also be specified for a find with extended info).

This closes feature request #285 by Phil (@plt).

WWIV writes 2 lines of metadata to the beginning of its quotes.txt file created for external message editors. Its not clear yet what these lines should contain, but the first line apparently should contain a '#' character since BREdit checks for this character before deciding to throw-away/ignore these lines (don't use them for quoted text). Thanks mlong for this tip!

So if the external editor is set to "WWIV CHAIN.TXT" in SCFG (even if the door doesn't need/use it), then the quotes.txt file created by Synchronet will contain the extra 2 lines. We're just writing a # to the first line and the second line is blank.

This fixes reported issue #188.

Slight usability improvement.

Expands to a percentage, similar to PCR (not capped at 100).

Remove the failed-attempt to cap the percentage at 100 for the PCR atcode.

Previously, the '*' matching pattern character could only be used as the beginning or ending character of a pattern string; for any other use, it was treated just as any other exact-match character.

Now, you can have exact-match characters on both the left and right sides of the '*', so pattern matching like the following is possible:

<*@gmail.com>
digital*man

Multiple '*'s are still not treated special (only the first/left-most '*" is), so, for example, "*blah*" will not likely produce the desired matching effect (use "blah~" instead for this case).

Eliminate some of the infrequent SPAM posts to the SYNCPROG conference. Maybe make this behavior configurable?

If anything, I suppose would be beep if a search fails, but really, I think beeps are kind of annoying these days. Not changing the currently selected/viewed user is likely all that's really needed to indicate a search failure.

Helpful for debugging issues with this forgery detection logic (if there are any).

When setting the value of a message's 'can_read' property, ignore the PRIVATE message attribute (which is sometimes set in FTN netmail messages) since it's assumed all messages in the mail base are private, no special destination (to) name matching is needed here.

This only popped up recently via msglist.js because of the recent addition of checking each messages's 'can_read' property.

As reported by <Diehard> via IRC PM.

What took down cvs/sbbs yesterday:
Program terminated with signal SIGSEGV, Segmentation fault.
6203                    session->req.post_data[session->req.post_len]=0;
[Current thread is 1 (Thread 0x7f2b989ff700 (LWP 17031))]
(gdb) print post_len
No symbol "post_len" in current context.
(gdb) print session->req.post_len
$1 = 0
(gdb) print session->req.post_data
$2 = 0x0

Fixes issue #276

Thanks Coverity! (CID 332340)

It's anticipated that this will be used for JS-populated file metadata in JSON format in the future (and not just "archive contents" in .ini format).

Also, fix the double-free issue that was occurring when moving files with extended file descriptions (sbbs_t::movefile()). This was actually the primary problem I was fixing here, but noticed the metadata issue: metadata would not have been moved along with the other file info between bases.

Constified function arguments. Source path is still case-insensitive, but destination is case-sensitive (hopefully that's not an issue).

When a "move" (!copy) is requested, a rename() is always attempted first and if successful, job done. Otherwise, we continue on with the file-copy (and then remove).

This should resolve CID 332219 (DEADCODE).

Not that it really matters, but perhaps it'll matter in the future. And the code reads better.

Hopefully this helps get to the bottom of Ragnarok's reported problem creating ZIP QWK files with libarchive.

If libarchive creates a 0-byte file or no file at all, then fall-through to the "temp file command-line" (if there is at least one Compressible File Type configured).

If libarchive fails, there will still be a (hopefully helpful) error message logged, but at least the QWK packet may still get created.

Not supported by default on Windows and perhaps not on all *nix systems.
You can still support creation of tbz files if you like, but you'll need to setup an external "Compressible File Type" in SCFG to do it.

This should fix issue #272 reported by Ragnarok. Not the libarchive error part, but the second (mv) CopyFile error part.

Sometimes the progress meter (e.g. during file text searches) appears at a column offset > 0 and doesn't look good. Fix that.

This resolve long delays (while searching for files) without any indication of progress.

Keep new-scan progress interval at 10 dirs however (they're fast).

We can't (apparently) only rely on the return value of start_tls(), we have to check the value of the crypt session too.
This fix the possibility of this happening:
Jun  7 18:07:26 sbbs synchronet: ftp  0058 TLS ERROR 'No permiss.to perform this operation' (-21) opening keyset
Jun  7 18:07:26 sbbs synchronet: ftp  0058 <192.168.1.25> initialized TLS successfully

Instead, we'll detect the failure and disable FTPS support, logging "failed to initialize TLS successfully".

Skip any prepended white-space in the passed name to find.
Use better variable names (and length) for the character strings.
Use matchusername() instead of strcmp(); matchusername() follows the liberal user-id/alias/name matching algorithm.
Use strcasestr() instead of strstr(), so no copy/modification (upper-casing) of passed name is now required.
When 'Q'uitting the search, set the SS_ABORT flag.

Don't need no stinking pre/appended white-space in our filenames!

5 options:
- Safest Subset
- Most ASCII, Excluding Spaces (the default)
- Most ASCII, Including Spaces
- Most CP437, Excluding Spaces
- Most CP437, Including Spaces

Fix FreeBSD build error:
dirwrap.c:760:13: error: use of undeclared identifier 'GLOB_PERIOD'
Not sure how glob() on FreeBSD treats "dot files" or how to control that.

sbbs_t::checkfname() now checks the file.can too.
new filedat.c functions:
- safest_filename() - not currently used
- illegal_filename() - returns true for a highly-suspicious (e.g. hack attempt) filename
- allowed_filename() - returns true if the filename is good for upload (assumed to be already checked to be legal as well).

Importantly, filenames beginning or ending in a '.' are now unallowed:
- 'dot files' are hidden (by default) on *nix
- files ending in a '.' are problematic on Windows

(prints the bad filename)
- also, checkfname() is going to do the file.can (trashcan) checking, so no need here