GitLab

When there's no "uploads" directory configured by the sysop, cfg.upload_dir will be set to INVALID_DIR, which cannot be used as an index into cfg.dir[] to determine if the time used for uploading the files should be "given back" to the user.

In v3.18, we used the first file in the upload queue, if there was one, else fell back to the "uploads" dir (which had to have been defined if there were no files in the queue). So this illegal array indexing was a regression in v3.19.

Reported by Zoltán Gábor on Facebook

Per https://man7.org/linux/man-pages/man3/pthread_yield.3.html
       This call is nonstandard, but present on several other systems.
       Use the standardized sched_yield(2) instead.

Should fix #299.

As reported by Ragnarok (DOCKSUD) via DOVE-Net, when packing (packetizing) netmail messages, the source and destination zones from the netmail header were discarded (since they are defined as "optional" in FTS-1) and the zone values were replaced with the system's primary/default zone number. If the netmail message included an INTL kludge, the source and destination zone values would be parsed from that kludge line and this issue would not be noticed. 

So the fix is: Only if the netmail message header contains a source or destination zone number of 0, replace that zone with the system's primary/default zone number. As before, the INTL kludge zone information can override the header fields.

Also, there's no reason to force the point numbers from the header to zero, since if they were not valid (e.g. "fill" in the original FTS-1 specification), they would be already zero. So use the source and destination point numbers, as is, from the netmail header too (with the FMPT and TOPT kludge override support left in-tact).

At Nelgin's suggestion, if all the messages in a packet are either good or bad, say so (since no .good or .bad file will be generated in that case).

Most Ctrl-A code terminal/attribute effects can now be invoked via @!x@ where x is one or more Ctrl-A sequence operands (e.g. @!B@ to set the current attribute to blue, @!P@ to pause the terminal). Multiple attribute codes may be specified in a single @!x@ sequence. Both upper and lowercase attribute codes are supported. The "^A@" sequence is not supported, but there's already an @-code to perform the equivalent operation ("SHOW:20").

Rationale: when using PabloDraw to edit display (e.g. .msg) files, there was no easy way to explicitly clear (set to "normal") the current attributes at the end of a line of text. If that line of text contained a background color and the line caused the terminal to scroll, that background color would fill the next/new line resulting in some potential undesirable effects. There are 2 common solutions to this problem: either clear the screen before displaying the file (not always desirable) or clear the attributes at the end of the line (before the CR/LF). This can now be achieved by adding a @!N@ (the equivalent of Ctrl-AN for "normal" attributes) to the end of a line. There's no way to insert custom Ctrl-A sequences or other way to force PabloDraw to clear the attributes at the end of a line, that I found.

I chose the '!' character because it's (on my keyboard anyway) the Shift-1 key and Ctrl-A is ASCII 1. I considered a sequence such as @A:x@, but that's one more character and since this sequence usually won't display anything, a shorter sequence is likely preferred. For the shortest-possible sequence, use Ctrl-A sequences instead. However, for many consecutive Ctrl-A sequences, the @-code equivalent might actually end up being shorter(!). @-codes aren't support in as many places in Synchronet where Ctrl-A codes are supported (for security reasons), so it's not like this is going to replace the use of Ctrl-A codes everywhere.

SEX is the user's sex/gender
GENDERS is the list of system-supported genders for new users to choose from.

When this function was called multiple times (e.g. multiple messages in a pkt),
it would keep appending to the current (static) string, eventually overflowing
the buffer and corrupting the stack. Although reported in pktdump, it could
have also happened with fmsgdump if passed multiple stored message (.msg) files.

Fixes #295 reported by Nelgin

Up to 40 characters can be configured by the sysop for gender options.
The default choice/configuration is now: "M/F/X" (not just "M/F")
New @-code: GENDERS
text.dat EnterYourSex -> EnterYourGender

Closes enhancement request #291 by Ragnarok

As discovered by Keyop and reported via IRC, when replying *to* a local mail box and *not* using the hard-coded email menu (e.g. when when using msglist.js), the original message's "Replied" attribute flag was not set. When replying to a netmail address (at least, Internet or FidoNet, unsure about QWKnetmail), the attribute would be set.

This discrepancy was because this email() function doesn't use the  "modern" smb_addmsg() function (which also calls smb_updatethread()), but add the message body text the old/manual way and never called smb_updatethread(). smb_updatethread() does the thread linkage stuff (which is usually unnoticed in the mail base) *and* sets the "Replied" attribute of the original message, if it's not already set.

This function should be overhauled to use smb_addmsg(), but this 2-line change at least addresses this issue for now. There's probably other places (e.g. importing mail replies via QWK/REP packets) where this thread-linkage and "Replied" attribute flag setting is still not happening.

write()
chsize()

Follow-up to previous commit for Keyop (extending max area tag length from 35 to 40/50 chars), when importing echolists/areas.bbs files, if the area tag is longer than 40 chars, then import it into the newsgroup name field instead (63 chars max).

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".