These functions take a uint32_t, not a time32_t (which is an int32_t).

Every SFTP login/off would reset the user's new-file-scan date to Jan-1-1970

To support the full 32-bit range for things like dates/times, and message
numbers (!).

This should fix issue #732

Though dates beyond Feb 7 2106 are definitely going to still be an issue. I'll
definitley look into solving that by the the 2100.

See sbbs_t::logon() for example

Note: the client.protocol is still "SSH" here (not "SFTP"). Perhaps that
should be changed?

Does any client actually support simultaneous "SSH" and "SFTP" sessions over
the same socket?

Found by Coverity.

The array overrun crashed Win32, the asprintf() usage imacts glibc
and the other warnings are impossible (an exception would have been
thrown).

This includes the "OK" error, and numerous other normal errors,
so most of them are logged as LOG_DEBUG.

Also fail early if parsing underruns root.

This Win32 function behaves differently on Win32 than *nix, and
does not do what we want.

Instead, copy the important bits from xpdev, and resolve a TODO.

I'm not clear on why MSBuild can build the solution without this but the IDE
cannot (results in sftp.lib not found, unresolved SFTP symbols, etc.).

If a filename failed to be added for a readdir response, it would
have just skipped that file and continued with the files around it
rather than reporting an error.

The /vfiles root uses the configured virtual paths as in the FTP
and web servers.  These paths should be shorter than the ones used
in /files, and also have the benefit of translating slashes so
users will not need to type a Big Solidus if they're trying to
type long lib or dir names.

This should speed up directory listings over higher latency links
by approximately 25×.

You're welcome nelgin.

This should fix the sftp hangs...
While FreeBSD will return EDEADLOCK when a mutex would deadlock,
Linux will do what I ask and deadlock.

Since we're not checking the return value of pthread_mutex_lock(),
this would go completely unnoticed on FreeBSD, resulting in the
mutex being unlocked early and all sorts of unprotected accesses
would happen, potentially doing crazy things.  On Linux it just
deadlocks, and taking a peek at the thread backtraces makes the
problem obvious.

So, point to Linux for making life more correct for people who
do incorrect things (locking without checking the return value).

I'd also like to thank nelgin, for sticking with me on this issue
and being my gdb puppet.

And really, this commit should be shared by all the contributors
who... 𝆺𝅥𝅮𝆺𝅥𝅮𝆹𝅥𝅯𝆹𝅥𝅯

This prevents the case where input_thread() accepts the sftp
connection and calls init_sftp(), then answer() does the same thing,
clobbering the previous state.

but does not yet have a session type.

Also, fix what appears to be a fairly blatant memory leak.

If there's an error setting the channel or getting the channel
type, give up on the session immediately.

In this case, just accept whatever we get info on as the "first" one.

Likely fixes #728

If the SSH_ANYAUTH option is set, the server will accept the "none"
authentication method, and not even suggest the client send a
password or public key.

The client must still send a user ID, but we just ignore it
completely and don't even log it.

This blindly accepts whatever authentication the remote offers, but
does not log into the BBS, dropping the user at the login prompt
instead.

Closes #726

You're welcome Keyop.

The other 500 times are implied.

The reason the comparison was changed to <= 0 is to do an explcit
check that eliminates negative numbers rather than the implicit ones
with the greater-than checks.

It seems that GCC is concerned that we can't create a sftp_dirdescriptor_t
or sftp_filedescriptor_t?

If user is being kicked off for being on "More than one node at a time", then
don't send a message to other any other nodes that the user logged-on
successfully (they haven't). Previosuly, it'd send messages to all the
lower-numbered nodes that were in-use (but not by the same user).

Reported by Nelgin.