And only supports a single file per invocation now.

It makes a difference on *nix.

So this change is needed or else fcntl() will fail with errno=BADF if trying
to write-lock a file that was opened read-only. Oh well. Added a comment
explaining the rationale.

OFD locks are needed on Linux for appropriate multi-threaded shared file
access (using fcntl record locks to prevent corruption), so log a warning if
building for Linux without that support.

lock() now mimics DOS/Windows again: the result lock is an "all access" lock
regardless of what mode the file was open in. I'm not sure why this change was
made (commit 11b73134), but I don't think it was necessary or
appropriate (though I can't think of any immediate negative effects). At
minimum it makes the code a little more understandable and eliminates an
extra call to fcntl().

This is the program I used (along with flock) to reach the root cause of
the SH_COMPAT == SH_DENYRW (no locking) bug in sopen() as well as other
interactions between Linux and Windows clients opening the same files
across a Samba share.

You can't lock a file on a Samba share via both fcntl() and flock() (the
interact/collide).

This code was in a !BSD block which means they guy that wrote/committed
it wasn't using it either.

SH_DENYRW (deny-all) locks were broken 18 years ago with commit b866f199.

This fixes that by treating SH_COMPAT the same as SH_DENYNO (only), rather
than the same as SH_DENYNO or SH_DENYRW (and performing no locking).

This is likely the/a root-cause of some SBBS file corruption on *nix systems.

It appears Deuce's FreeBSD patch isn't going to be accepted/merged
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=50827), so I'm
making this code a little more readable/manageable by removing this
unused feature... for now, with Deuce's approval.

This solves issue #817 for TLDR messages imported into DOVE-Net Tech Talk,
because those messages are imported via SMTP originally and thus have the
original (MIME/Q-encoded subject) in the message header (as RFC822SUBJECT).

For other messages with UTF-8 characters in their header fields (e.g. subject),
we'll need a different solution (Q-encode header fields that contain
non-ASCII chars on the fly), and then this solution could maybe be reverted.

GCC and Coverity (x 2) both flagged this one.

Properly read the index of the base, not of the base_code.
Fixes badly broken STATUS command.

Also, change the default smb_t.retry_delay from 250 to 100ms

Getting a lot of smb_locksmbhdr() failures with sbbs-Linux accessing message
bases (i.e. SYNCPROG in particular) on Samba share.

Similar to what I do with user.tab record locks 2 months ago, this will
extend the total shared/network file open attempt duration from about 5
seconds to about 45 seconds, but with incrementing back-off.

Trying to sbbs-Linux to run from a Samba share without file open/locking
errors.

Re-synced the sbbs_t version of nopen with the nopen.c version (wasn't
special-handling EDEADLOCK failures).

Mostly we're using fnopen() these days anyway, which doesn't have an sbbs_t
version (for logging warning messages about collisions), perhaps it should.

This date (basically 0) means either the dsts.ini file doesn't exist or there
was an issue reading it successfully (that was not detected by getstats()).

If this works, we can use it for EVERYTHING!
Baw ha ha!

Use sdl-config before falling back to the framework.
Move sdjclean into objodir and link with mt stuff.

Also fix last commit

So dos2unix 'em all.

When using MacPorts (and likely Homebrew), this isn't how this works.

New versions still support that.

This was a regression: Socket.recvline() used to not care what the timeout
duration was so long as there were bytes to receive.

Also, remove the ".0" from timeout values in documented mehtods that don't
(any longer) accept floating point timeout durations. We used to support
fractional seconds for some of these methods, and that was implied by using
the floating point default values, but that's no longer the case. poll()
still accepts a floating point timeout.

This was just a typo which didn't allow the single-file upload xfer prot menu
to be shown.

Actual fix for CID 11447 (previous attempt, commit f50c866f was
insufficient). Thank you Coverity!

It's slow and crufty, and there's a new mini on the block now.

Should fix OpenBSD builds.

It's super-picky.

Use standard isfinite() instead of never-standard finite()
Don't use -rpath-link on darwin (since it won't work anyway)

Rather than trying to back-port platform support, just grab the
latest libffi release and jelly it in.

Let's wee what the pipes tell us.

That's the key!

Ugh.