https://gitlab.synchro.net/main/sbbs/-/commit/a6dd4c68cdba571f7712e1a1
Modified Files:
src/sbbs3/nopen.c
Log Message:
A little paranoia around comparing a file date/time against current date/time

The file could be timestamped in the future (especially on a network FS).
We could maybe have been considering the lock too old (e.g. for REP packet unpacking) in this case and explain some of the collisions I see between
even threads on different machines unpacking the same REP Packet (or trying to), leading to errors like this one:
!ERROR 16 (Device or resource busy) renaming /sbbs/data/file/0290.rep
(20480 bytes) to /sbbs/data/file/0290.rep.697b1a12.bad

This shouldn't be possible if the mutex files are working as designed.

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

https://gitlab.synchro.net/main/sbbs/-/commit/dc6bd4c4071ed724f1eba26a
Modified Files:
src/sbbs3/nopen.c
Log Message:
Backups no longer widen a file's permissions

fcopy() opens the destination with nopen(), which creates it DEFFILEMODE
& ~umask -- typically 0644 -- so the copy's permissions had nothing to do
with the source's. That is the same omission just fixed in xpdev's
CopyFile() (GitLab #1202), but here it can make a file MORE accessible
than the original rather than less useful: the only caller is backup(),
and on its copy path it backs up user.tab and the user index, the mail
base, sbbs.ini, and SBBSecho's configuration -- which holds node
passwords. Under the default umask, a backup of a 0600 file was
world-readable at 0644.

The same function was also inconsistent with itself: backup()'s rename
path preserves the original's mode, because rename() keeps the inode, so whether a backup was readable by everyone depended on a flag its callers
pass for unrelated reasons. It already restored the timestamp explicitly
after copying; permissions were the omission.

fstat() the source descriptor and fchmod() the destination to match,
masked to 0777 so set-user-ID and set-group-ID bits are not propagated.
Guarded for *nix, as fchmod() has no Windows equivalent and file modes
there do not carry this meaning.

Measured before and after, umask 022, against source modes 0600, 0640,
0660, 0644, 0755 and 04755: every destination was 0644 before; each now
matches its source, with 04755 landing as 0755.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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