https://gitlab.synchro.net/main/sbbs/-/commit/658773d65b44452a84a696fb
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Log the full path for rejected uploads based on directoryThe logged error "!attempted to upload to invalid directory" did log the actual path that was attempted to be uploaded.Added some quotes around other logged paths.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/52b2e20a5dd8330adb315d73
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Change "attempted to upload to invalid directory" msgMake it more accurate/clear:"attempted to upload invalid path/filename"
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/5fdf8f0fddbcc5016c033af8
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Don't MQTT-publish the download of temp files
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/8e94a448a7346a36d4a85dbe
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Fix uploader-notification, credit awards, download-counters in FTP downloadsSince v3.19 (the new filebases), when a user FTP-downloaded a file, we failedto properly find/load that file's record from the filebase (searching for thefile's full path, rather than just the filename), so the code the incrementsthe file's download counter, notifies the uploader, awards credits, etc. didnot ever execute. This means that FTP-downloads for all files downloaded viaFTP were effectively "free" (and nobody noticed). No error was logged either.I discovered this while debugging the case of "(null)" filenames in theaction/download MQTT topic messages being published by the FTP server. Sothat issue is fixed as part of this commit as well.Oh, and if this code had executed before, it would have memory-leaked thefile information, so that's fixed too (added call to smb_freefilemem). Ugh.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/3709ae9d438cc0932f70c46f
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Free/zero out the file_t struct *after* sending the MQTT action msg... not before. This explains why FTP-uploaded actions had a (null) filename.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/448e18156d14b0b8a2bb535a
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Add free disk space check against minimum space configuredDisallow uploads when free disk space falls below minimum configuredminimum free disk space.This fixes issue #535
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/2e93426824b48954395c0b1f
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Fix some signed/unsigned comparison warnings from MSVC
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/3e2c3176de6108c697d25a69
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Fix false "SUSPECTED BOUNCE ATTACK ATTEMPT" for IPv6 FTP-data connectionsThis bug only impacted non-passive FTP connections. Using an FTP clientwith active (not passive) data connections over an IPv6 connection wouldfalse-trigger the "bounce attack" detection and the FTP server responded with"504 Bad port number" and logged a hack attempt in data/hack.log.The issue was that we were comparing the socket address structure (whichcontains other fields besides the address itself) between the control andproposed-data connections. While this logic worked okay for IPv4,it did not for IPv6 (the 2 structs contained some non-address differences).Rather than modify the socket address structures to match where needed, I'mjust comparing the string representation of the addresses, since that'swhat we really care about anyway.Thank to "mark i" of Truck Stop BBS for alerting me to this issue
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/5d903235ca2629f59dc78999
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Log errno description upon QWK pack mutex file creation failure
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/339599be4e8c05ed8e3fabe9
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Fix MSLT and MSLD response for QWK packet filename in root directory

Reusing the variable 'str' here for multiple purposes meant the QWK packet filename was overwritten by the owner name (the system's BBS-ID):

mlsd

229 Entering Extended Passive Mode (|||2001|)
150 Opening ASCII mode data connection for MLSD.
Type=file;Perm=r;UNIX.ownername=VERT; 00index
Type=cdir;Perm=elc;UNIX.ownername=VERT; /
Type=file;Perm=r;UNIX.ownername=VERT; VERT

That last file there should have been "VERT.qwk"
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e1b0164230ba4987cae0c3df
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Mostly time_t printfs, but also an odd bit where it's printing a
value that's not an off_t as one.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/0ca7156dc5215b928bf5a689
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Reduce log severity of QWK-packet removal error log message to WARNING

This allows each call to ftp_remote() to specify the log level for any remove failure. All others file-removal failures will continue to log at ERROR level.

I get this particular (harmless) error a lot, so just reducing to warning:
ftp ... !ERROR 13 (Permission denied) (line 860) removing file: path/to/*.qwk --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/05420809878c8fd7f272fa87
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
ftp_remove() returns a bool (not an int) now, so do the right thing
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/51ce7e6f71c2009c1804679f
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Attempt to fix issue #799

receive_thread() needs to use the control session correctly for
TLS connections.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/17912ca377006ca652483b1e
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
IP addresses are logged (most) everywhere else in square brackets

There are still places where it could be logged in <> (if username is not yet known).
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/ffba326dad6263eedc29ed94
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Fix the "ERROR x getting data user y" log message (usernum was 0).

Add the errno value to help root-cause.

We really should be using safe_strerror() everywhere.
--- SBBSecho 3.22-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/569efded81398f71ad35f70b
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Use safe_strerror() in place of strerror() - everything multithreaded should --- SBBSecho 3.22-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/6fc2a6b6ff98fab8f98bf955
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
A little beautification of errno logging
--- SBBSecho 3.22-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/8b4d02103bb4a63ffcc360f3
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Correct initialization of fmutex_t so the file descriptor is -1

For some reason, MSVC was initializing the time_t (second element of the struct) to -1, not the int fd (the first element), which was initialized to
0. Weird.
--- SBBSecho 3.22-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/ftpsrvr.c
By: Rob Swindell (on Windows 11) to Git commit to main/sbbs/master on Mon Nov 18 2024 01:50 am

For some reason, MSVC was initializing the time_t (second element of the struct) to -1, not the int fd (the first element), which was initialized to 0. Weird.

Actually, this assessment was wrong. fmutex_open() was memsetting the fmutex_t to zero.
--
digital man (rob)

Synchronet/BBS Terminology Definition #88:
UART = Universal Asynchronous Receiver/Transmitter
Norco, CA WX: 61.5øF, 38.0% humidity, 2 mph W wind, 0.00 inches rain/24hrs
--- SBBSecho 3.22-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)