https://gitlab.synchro.net/main/sbbs/-/commit/b73ac2b9c7affe55b51c47c5
Modified Files:
src/sbbs3/ftpsrvr.cpp
Log Message:
ftpsrvr: pack QWK and import REP packets in-process via qwkjob

A QWK download (RETR <qwk-id>.qwk, and SIZE/MDTM of that name) used to
create a data/pack<user#>.<host>.now semaphore and poll for up to
QwkTimeout seconds while the Terminal Server's event thread built the
packet. An FTP-only instance, or one whose event thread was busy or
disabled, timed out with "451 Time-out waiting for packet creation."
The control thread now calls qwkjob_pack() itself:

- no new messages: 550 (unchanged); logged-in at a terminal node: 550
Logged-in elsewhere
- the user's pack lock is held (another session, script or host is
packing or importing for the same user): immediate 451 "Packet
creation already in progress" (unchanged text)
- the per-process job cap is reached: retry once a second for up to
QwkTimeout, then the unchanged time-out 451, so QwkTimeout keeps its
meaning as the longest a RETR waits
- if the client disconnects, the pack still completes and the packet
stays in data/file/ for the next RETR

A REP upload (STOR <qwk-id>.rep) is now received into <temp>/rep/<user#>.<socket>.rep and imported by the receive thread
after the file is closed and before the 226, instead of being left in data/file/ for the event thread. A packet that fails to import is kept
as data/file/<user#>.rep.<hex-time>.bad (an empty one is removed) and
the client still gets 226, since uploading it again would not help.
When the user's lock is held or the job cap is reached, the REP is
queued for the event thread's sweep as data/file/<user#>.rep, or <user#>.<hex-time>.rep if a REP is already pending; temp and data can be
on different volumes, so a failed rename falls back to a copy under a
name the sweep ignores, then a rename. The control connection's
inactivity clock is reset after the import.

QWK job log lines are prefixed "ftp" and go through the server's own
log function (so LOG_ERR lines reach error.log and MQTT).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/7dd262f012ca4801e1322c22
Modified Files:
src/sbbs3/ftpsrvr.cpp
Log Message:
ftpsrvr: only treat the QWK reply packet upload as a REP

The receive thread decided an upload was a QWK reply packet from its
directory number (-1), but a sysop's local file system STOR/APPE is
also received with directory -1. Such an upload was then run through
the REP import: moved to data/file/<user#>.rep.<hex-time>.bad, deleted
if empty, or queued as data/file/<user#>.rep (or imported, if it was a
valid REP), so the file vanished from its destination while the client
got "226 Upload complete". The STOR <qwk-id>.rep branch now marks the
transfer explicitly and passes that to filexfer().

Also:
- Stage a cross-volume copy of a queued REP as <user#>.<socket>.tmp
rather than .reptmp: on Windows "*.rep" also matches 8.3 short names,
whose extension for .reptmp is .REP, so the sweep could pick up a
partial copy.
- Report EEXIST when no free queue name is found, instead of whatever
errno was left over.
- Reset the control connection's inactivity clock after a QWK pack, so
a pack that takes longer than MaxInactivity doesn't drop the session
on the next read.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/8371e30134a3dd298c731205
Modified Files:
src/sbbs3/ftpsrvr.cpp
Log Message:
ftpsrvr: keep a REP import off the control thread's stack

receive_thread() imports a received REP before its 226 reply, which can
take a while, and read the user number and alias through xfer->user,
which points into ctrl_thread()'s stack. When the server is going down
(ftp_set is NULL), ctrl_thread() waited only 2 seconds for the transfer
before returning, leaving the import to read a dead stack frame and, after
it, to write *xfer.lastactive there.

The transfer now carries the user number and alias by value for the
import, the post-import activity stamp is skipped during shutdown like
the existing *inprogress update, and ctrl_thread() keeps waiting (up to
60 seconds) while the transfer is in progress. The receive thread is
counted in thread_count, so the server's cleanup still waits for it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)