On Windows s3d was stopped with TerminateProcess. One killed during an
upload (a Theseus restart, a cut-off flush) had deleted four buffered
files without recording them as uploaded; every flush afterwards failed
on them and the files were gone.
A stop now waits while a flush Pithos started is running, or while s3d
has begun an upload batch in the last two minutes (up to five minutes;
twenty seconds when the host is quitting), then asks s3d to shut down
cleanly: Ctrl+Break sent to its own hidden console on Windows (Windows
disables Ctrl+C in a new process group; Go reads both as an interrupt),
SIGTERM elsewhere. It is ended by force only if still there a minute
later. Checked against s3d v0.2.0: 'shutdown complete', exit code 0.
After adding another account, opening a page failed with "failed to open
database: table users already exists": a users list ran while s3d was
starting, and both set up the fresh database. A start now waits for
running commands to finish, and commands wait while s3d is starting.
s3d is driven entirely by a CLI and a two-route admin API, which keeps
Sia storage out of reach for anyone who does not live in a terminal.
Pithos wraps it: install the pinned s3d release (checksum verified),
start/stop and logs, indexer login, users and access keys, a bucket and
object browser with share links and public-read policies, and the
upload pipeline stats.
One control server (core/) serves one UI (ui/), and three hosts run it:
a web console, an Electron desktop window and a Theseus add-on, so a
feature lands everywhere at once. The server binds loopback, rejects
foreign Host headers, and signs views in with a one-time secret that
becomes a SameSite=Strict cookie. s3d login reads the recovery phrase
with term.ReadPassword, so it is driven through a pty, with a console
window fallback where the pty module is not shipped.
