https://gitlab.synchro.net/main/sbbs/-/commit/6c0e423a38920f64abfb7013
Modified Files:
src/sbbs3/userdat.c
Log Message:
Don't truncate a user's record if the default download protocol or gender are '\0'

A blank download protocol field in a user.dat, when parsed, sets the 'prot' field
of user_t to 0. When writing the record back to the user.dat, this would prematurely
truncate all other fields off the user record (since strings in C are NUL terminated
and we're using sprintf() to format the record and %c specifier for that field).

The fix is to write a ' ' character instead of '\0' if the user_t.prot is '\0'. As part of this fix, I'm writing a '?' if a user_t.sex is '\0' (not sure if this
is actually possible, but just as insurance). Those are the only 2 single-character
user properties/fields today.

Bug reported/debugged by Al of The Rusty Mailbox (1:153/757.2) - thank you!

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/14125aa4b0aa0bf027f77361
Modified Files:
src/sbbs3/userdat.c
Log Message:
The NoAccess* text.dat strings are not appropriate 'reason' codes

These text.dat strings require an argument (and normally used with the NOACCESS @-code which uses the noaccess_str and noaccess_val member variables), so not appropriate to use as a reason code here. Use more generic (no argument) text.dat item numbers instead.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/edc931be6282acafdf043532
Modified Files:
src/sbbs3/userdat.c
Log Message:
More strict login-by-user-number support (parsing logic)

Before now, if the sysop enabled login-by-user-number and the specified login ID *started* with a decimal digit, it'd be treated as a user number and converted to a 32-bit integer. This could result in weird stuff, like this error I got today:
SMTP ... !ERROR -2 getting data on user (7000401005.gc7gg@synchro.net)

7,000,401,005 is clearly greater than the number of users in my user base
on Vert, but since 7B is > 2.1B (0x7fffffff), the number would be parsed as
a *negative* integer value and thus less than the total number of users in my userbase.

An obvious solution would be to just turn of login-by-user-number, and for
most systems, I suggest doing that (a system is less secure with it enabled).

However, I want to leave the option for sysops (at least for now) and don't want this weird behavior so, a login by user number now requires that the entire login ID is just decimal numbers, nothing else, and the number is
parsed as an unsigned integer. So yes, roll-over can happen for very high numbers (>4.2B), but in no instance will the number be parsed as negative and thus lead to an invalid user record look-up attempt.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e0979e270d947bc8a9e64e70
Modified Files:
src/sbbs3/userdat.c
Log Message:
Fix GCC 9.4.0 warning reported by Nelgin

warning: format not a string literal and no format arguments

Weird this warning is happening for me with GCC 12.2 (debug or release build)

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c1d6e2c764781b0400578600
Modified Files:
src/sbbs3/userdat.c
Log Message:
The "user" directory is special: you don't need "access" to download from it.

When sending a user-to-user file transfer, SBBS (since v3.19) will check that the file recipient will be able to download it (e.g. doesn't have restrictions preventing it) and this was failing for most (non-sysop) recipient users since they wouldn't normally meet the "access restrictions" of the user directory
(by design).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/68d9c3265f981c3579115177
Modified Files:
src/sbbs3/userdat.c
Log Message:
Truncate attempted user-name at '@' before comparing against name.can file

'@' is in the name.can by default and the mail server recognizes user@addr formatted logins/attempts, so truncate at the '@' before comparing against
the name.can file to prevent false !TEMPORARY BAN (1 login attempts, ... occurences.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/39b718dd3ea96ef9f70b5575
Modified Files:
src/sbbs3/userdat.c
Log Message:
Fix typos in comments

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e675cd6612c6723d40063f44
Modified Files:
src/sbbs3/userdat.c
Log Message:
Fix bug with parse_birthdate() in year-first format

The year is 4 digits, so the offsets aren't the same as the other 2 supported formats. Doh!

Thanks Max for testing!

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3bf7380f569eababc753e3fc
Modified Files:
src/sbbs3/userdat.c
Log Message:
nodestatus() print internal code rather than xtrn number, if possible

(as a fall back to the full external program name).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d6293e05bccdff9ff8fbb1c8
Modified Files:
src/sbbs3/userdat.c
Log Message:
Fix logic to add the "partially" prefix to download notification messages

The file_t struct may not have the size of the file pre-poulated, so we needed to call getfilesize() here.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e7642321545ef80fb73fe183
Modified Files:
src/sbbs3/userdat.c
Log Message:
Fix getnodedat() error handling and usage

If a file descriptor is passed to getnodedat() and the lock retry counter was reached, the file would be closed, but the passed file descriptor reference would not be set to -1. This could result in exceptions (from subsequent read attempts on the referenced file descriptor) in cases where the node.dab could not be locked or read by getnodedat() and was thus closed.

The set/get_node_* helper functions (used by MQTT) were not initializing the node.dab file descriptor (i.e. to -1), so it's possible getnodedat() could
try to read from and close an invalid/wrong open file descriptor. If the local variable happened to be initialized to a value <= 0, then, no problem, but
this is undefined behavior (UB).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/69fc70ab9e59914f5bfceb9f
Modified Files:
src/sbbs3/userdat.c
Log Message:
Extend (and back-off) the user.tab record lock attempts

I'v been getting errors locking user.tab (for read) for a while (over samba), so hopefully this helps. The lockuserdat() total timeout duration extends from about 5 seconds to about 45 seconds (with an incremental back-off).

Implement the same lock-retry logic/limit in putuserdat().

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3de5f432ff45b91c838f28c8
Modified Files:
src/sbbs3/userdat.c
Log Message:
Delete data/file/*.out directory for new user (if exists)

emailfiles.js puts files here that the user requested to download "via email" and might not have been successfully delivered and deleted. So clean-up.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net