https://gitlab.synchro.net/main/sbbs/-/commit/339ec9da469f2cd95f72b8fe
Added Files:
src/doors/syncdoom/deploy.bat deploy.sh src/doors/syncduke/deploy.bat deploy.sh
Modified Files:
src/doors/syncdoom/COMPILING.md build.bat build.sh src/doors/syncduke/README.md build.bat build.sh
Log Message:
syncduke/syncdoom: split deploy out of the build into deploy.sh/deploy.bat

Building no longer auto-installs the binary into a live xtrn dir -- build.sh / build.bat now only produce build/<door> (build-msvc\Release\<door>.exe on Windows), and a new deploy.sh / deploy.bat carries it to the door's xtrn dir(s) on demand. A sysop can rebuild and test before pushing a new binary to a running BBS.

This also fixes a 0-byte-binary bug on SYMLINK=1 installs where the live xtrn/<door>/<door> is a server-side symlink back to the build output, exposed over an SMB mount as a plain file on a different device. The old in-build
`cp -f "$EXE" live/<door>` had source and dest resolve to the same physical file, but `-ef` and cp's same-file guard compare st_dev/st_ino -- which differ across the mount -- so cp opened the dest O_TRUNC and zeroed the build output to
0 bytes before reading a byte. deploy.sh guards against it two ways: skip when the dest already has identical content (catches the cross-mount self-reference -ef misses, and preserves the symlink), and otherwise copy via a temp file + atomic rename so the source can never be the O_TRUNC victim. deploy.bat skips via `fc /b`.

Docs (syncduke README, syncdoom COMPILING) updated for the two-step flow.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net