https://gitlab.synchro.net/main/sbbs/-/commit/17a67ee9d95051145677ec52
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Fix FTPS upload failure: !DATA ERROR 0 receiving on data socket

Don't treat CRYPT_ERROR_COMPLETE (-24) as a socket error during upload since it's an indication that the remote closed the connection and is the normal "end of file/transfer" indicator, not an error. 'rd' is already 0 in this case, so no need to set at all (since recv() returns 0 upon disconnect and that's what we're emulating here).

Fixes issue #309 reported by Jas Hud.

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

Re: src/sbbs3/ftpsrvr.c
By: Rob Swindell to Git commit to main/sbbs/master on Sun Dec 05 2021 06:42 pm

https://gitlab.synchro.net/main/sbbs/-/commit/17a67ee9d95051145677ec52 Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Fix FTPS upload failure: !DATA ERROR 0 receiving on data socket

Don't treat CRYPT_ERROR_COMPLETE (-24) as a socket error during upload since it's an indication that the remote closed the connection and is the normal "end of file/transfer" indicator, not an error. 'rd' is already 0 in this case, so no need to set at all (since recv() returns 0 upon disconnect and that's what we're emulating here).

Fixes issue #309 reported by Jas Hud.

i cant upload files using any protocol on your bbs and cvs.synchro.net
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

Re: src/sbbs3/ftpsrvr.c
By: MRO to Rob Swindell on Mon Dec 06 2021 01:35 pm

Fixes issue #309 reported by Jas Hud.

i cant upload files using any protocol on your bbs and cvs.synchro.net

Working for me (now). I replied to your emails about this already. I appreciate your continued testing.

Don't try to use SyncTERM v1.2b for uploads (they don't work).
--
digital man (rob)

Synchronet/BBS Terminology Definition #14:
CGA = Color Graphics Adapter (IBM)
Norco, CA WX: 72.0øF, 35.0% humidity, 8 mph NNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: src/sbbs3/ftpsrvr.c
By: Digital Man to MRO on Mon Dec 06 2021 01:20 pm

Re: src/sbbs3/ftpsrvr.c
By: MRO to Rob Swindell on Mon Dec 06 2021 01:35 pm

Fixes issue #309 reported by Jas Hud.

i cant upload files using any protocol on your bbs and cvs.synchro.net

Working for me (now). I replied to your emails about this already. I appreciate your continued testing.

Don't try to use SyncTERM v1.2b for uploads (they don't work).

yeah i tried to delete this msg but it already sent.
i'm using 1.1b win32 of syncterm
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

Re: src/sbbs3/ftpsrvr.c
By: MRO to Digital Man on Tue Dec 07 2021 02:58 pm

Re: src/sbbs3/ftpsrvr.c
By: Digital Man to MRO on Mon Dec 06 2021 01:20 pm

Re: src/sbbs3/ftpsrvr.c
By: MRO to Rob Swindell on Mon Dec 06 2021 01:35 pm

Fixes issue #309 reported by Jas Hud.

i cant upload files using any protocol on your bbs and cvs.synchro.net

Working for me (now). I replied to your emails about this already. I appreciate your continued testing.

Don't try to use SyncTERM v1.2b for uploads (they don't work).

yeah i tried to delete this msg but it already sent.
i'm using 1.1b win32 of syncterm

1.1 was released over a year ago. That's the supported/known-working version. 1.1b (for SyncTERM) means "beta" or pre-1.1.
--
digital man (rob)

This Is Spinal Tap quote #39:
Female Airport Security Officer: Do you have any artificial plates or limbs? Norco, CA WX: 54.1øF, 85.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: src/sbbs3/ftpsrvr.c
By: Digital Man to MRO on Tue Dec 07 2021 07:45 pm

yeah i tried to delete this msg but it already sent.
i'm using 1.1b win32 of syncterm

1.1 was released over a year ago. That's the supported/known-working version. 1.1b (for SyncTERM) means "beta" or pre-1.1.

yeah, it works for what i use it for so i'm not going to upgrade.
it's not bombing out on me during connections.
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

https://gitlab.synchro.net/main/sbbs/-/commit/7ccc618a991a97d22336fcc0
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Log unallowed/illegal filenames in quotes

Prefixed or trailing white-space characters would be hard to discern without this.

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

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 directory

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

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

https://gitlab.synchro.net/main/sbbs/-/commit/52b2e20a5dd8330adb315d73
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Change "attempted to upload to invalid directory" msg

Make it more accurate/clear:
"attempted to upload invalid path/filename"

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

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

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

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 downloads

Since v3.19 (the new filebases), when a user FTP-downloaded a file, we failed to properly find/load that file's record from the filebase (searching for the file's full path, rather than just the filename), so the code the increments the file's download counter, notifies the uploader, awards credits, etc. did not ever execute. This means that FTP-downloads for all files downloaded via FTP were effectively "free" (and nobody noticed). No error was logged either.

I discovered this while debugging the case of "(null)" filenames in the action/download MQTT topic messages being published by the FTP server. So
that issue is fixed as part of this commit as well.

Oh, and if this code had executed before, it would have memory-leaked the
file information, so that's fixed too (added call to smb_freefilemem). Ugh.

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

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.

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

https://gitlab.synchro.net/main/sbbs/-/commit/448e18156d14b0b8a2bb535a
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Add free disk space check against minimum space configured

Disallow uploads when free disk space falls below minimum configured
minimum free disk space.

This fixes issue #535

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

https://gitlab.synchro.net/main/sbbs/-/commit/36fea1c5acf774be516d1df6
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Limit uploaded file sizes, accounting for free disk space

The lower of the configured maximum file size (for the FTP server) and
the available disk space minus the configured minimum free disk space
is used as the maximum file size to allow upload. Appended files
are accounted for too.

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

https://gitlab.synchro.net/main/sbbs/-/commit/2e93426824b48954395c0b1f
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Fix some signed/unsigned comparison warnings from MSVC

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

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 connections

This bug only impacted non-passive FTP connections. Using an FTP client
with active (not passive) data connections over an IPv6 connection would false-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 (which contains other fields besides the address itself) between the control and proposed-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'm just comparing the string representation of the addresses, since that's
what we really care about anyway.

Thank to "mark i" of Truck Stop BBS for alerting me to this issue

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

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

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

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"

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

https://gitlab.synchro.net/main/sbbs/-/commit/3a25ed550b4f5d6563da0d8a
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Use safe string copying in get_owner_name() via strlcpy()

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

https://gitlab.synchro.net/main/sbbs/-/commit/bb4ccdaad2c07262560ddab9
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Restore ftpalias.cfg support for MLSx commands

Support was accidentally removed as part of commit 0d01544d, meaning
the ftpalias.cfg wasn't used at all in responses to the MLSx commands as reported by Max (WESTLINE) using Total Commander, FileZilla and Directory
opus. The traditional "LIST" commands still worked fine with ftpalias.cfg contents just fine.

The reason this code was accidentally removed was due to the errant
copy/pasted comparison with startup->html_index_file that did not belong here and made the block appear related to HTML index file generation. It was not. This was just a bug in the initial implementation of MLSx support in
commit d4deb4b3.

Also included in this commit:
- Return the date/size of the user's QWK packet file, if it exists, in MLSx
response.
- send_mlsx_entry() won't report negative time_t values as file modify dates
(flength returns -1 upon failure/file-not-found).
- get_owner_name() returns the string, making it easier to use in function
calls.

There appears to still be some work to do to make the MLSx commands fully compliant with RFC 3659 (e.g. "mlst filename" from ftpalias.cfg should work
but does not), but at least FileZilla displays ftpalias.cfg files and directories correctly now.

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

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.

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

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

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

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

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