https://gitlab.synchro.net/main/sbbs/-/commit/9a2e13855f0495f55bb2ea0f
Modified Files:
src/doors/syncretro/LAUNCHER.md README.md syncretro_io.c xtrn/syncarcade/README.md install-xtrn.ini syncretro.example.ini xtrn/syncivision/install-xtrn.ini xtrn/syncnes/install-xtrn.ini
Log Message:
syncretro: document where a *nix door's diagnostics actually go

The arcade README told a sysop to read data/syncretro/syncretro_n<node>.log
for the reason a romset was refused. That file only exists on Windows, or
for a -stdio door: those are the two cases where the door redirects its own stderr, because a console-less Windows launch has nowhere for it to go and
a stdio door's stderr is painted over the player's screen. A *nix socket
door -- what the lobby spawns by default -- leaves stderr inherited, and xtrn.cpp's wait loop drains it a line at a time into the server log. So on Linux there is no door log to find. The sysop-facing docs now say so, and
name the "[MAME 2003+]" / "Opening ROM file:" lines that identify which
file the core wanted.

Also corrects the opposite error in the dirty_log comment, which claimed a native door's stderr is eaten outright under EX_BIN. That applies only to
the EX_STDOUT (stdio) path; a socket door's stderr is relayed and does
reach the server log. dirty_log keeps its own file regardless -- a
per-frame trace has no business flooding the server log at a syscall per
line inside the frame loop.

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