1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/xpdev/filewrap.c

    From Deuc¿@VERT to Git commit to main/sbbs/master on Sun Mar 15 16:01:53 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/e4122aa602189ce9e5154c56
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Remove vestigial (int) casts truncating off_t lock length

    Both lock() and unlock() cast the off_t len parameter to int before
    assigning to alock.l_len (which is off_t). The cast silently
    truncates lock lengths on files > 2GB. Both sides are already off_t,
    so the cast is unnecessary.

    Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Jun 3 09:44:35 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/e3fd4e7cf195c14e9e12c577
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    xpdev/filewrap: flock path of xp_lockfile() honors fd open mode too (#1153)

    The non-Linux POSIX (flock) path of xp_lockfile() always took LOCK_EX,
    even for a read-only descriptor, unlike the Linux/fcntl path which
    derives the lock type from the fd's open mode. So on FreeBSD/macOS/etc. (USE_FCNTL_LOCKS is Linux-only) a read-only lock() serialized concurrent readers - the same exclusive-lock-on-reads issue fixed for Windows in the previous commit. flock() (unlike fcntl()) isn't forced to a lock type by
    the access mode, so the LOCK_EX was a choice; mirror the fcntl path and
    take LOCK_SH for an O_RDONLY fd.

    The user.tab read path is already covered on these platforms (rdlock()'s
    flock branch uses LOCK_SH); this brings the lock() primitive itself to
    parity, so any read-only-fd caller benefits. flock remains whole-file
    (pos/len ignored) - a pre-existing coarseness, unchanged here.

    Not compiled in this environment (the flock branch builds only on
    non-Linux POSIX); mirrors the existing fcntl-branch idiom.

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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sat Aug 8 18:05:04 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/7384ba6569de8ffbf0720f2d
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Close descriptors with closefrom() rather than close_range()

    closefrom() exists on the BSDs, Solaris and glibc 2.34 and later, where close_range() is a Linux syscall this code was reaching for directly. On
    glibc, closefrom() is implemented in terms of close_range() anyway, so
    calling it gets the better mechanism where there is one and a working
    fallback where there isn't, without this file having to know which.

    Keeping one descriptor no longer needs a range API at all: close everything above it in a single call, and walk the few below it. That loop is bounded by the kept descriptor rather than by the process descriptor limit, which can be very large. Platforms with neither call (macOS) still consult sysconf(_SC_OPEN_MAX).

    Also spell the first descriptor to close as STDERR_FILENO + 1 rather than 3.

    Suggested by Deuce.

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

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