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

  • src/xpdev/filewrap.c

    From Deucе@VERT to Git commit to main/sbbs/master on Sat Feb 10 22:28:17 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/1f2f00b04b06f3e9d595bb2f
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Fix misleading comment

    ---
    ￭ 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 Sun Nov 10 22:12:10 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/09f98728aecf1e7049d04168
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Get rid of the fcntl() usage in sopen()

    You can't lock a file on a Samba share via both fcntl() and flock() (the interact/collide).

    This code was in a !BSD block which means they guy that wrote/committed
    it wasn't using it either.

    ---
    ■ 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 Sun Nov 10 23:52:50 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/043feff892a3a206ed12e9cf
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Log a build warning if building for Linux without OFD lock support

    OFD locks are needed on Linux for appropriate multi-threaded shared file
    access (using fcntl record locks to prevent corruption), so log a warning if building for Linux without that support.

    lock() now mimics DOS/Windows again: the result lock is an "all access" lock regardless of what mode the file was open in. I'm not sure why this change was made (commit 11b73134563ce26), but I don't think it was necessary or appropriate (though I can't think of any immediate negative effects). At minimum it makes the code a little more understandable and eliminates an
    extra call to fcntl().

    ---
    ■ 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 Mon Nov 11 01:13:16 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/d9d86d6a36f9133ed5b08189
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Revert the lock() change in commit 043feff8

    So this change is needed or else fcntl() will fail with errno=BADF if trying
    to write-lock a file that was opened read-only. Oh well. Added a comment explaining the rationale.

    ---
    ■ 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 Mon Dec 2 20:29:33 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/77a771095c72121700e96ca2
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Don't use flock() in sopen() since it ends up using non-OFD fcntl() locks

    When OFD locks are available, that's what we should be using.
    Otherwise, we suffer the horrible behavior of POSIX file/region locks and
    a subsequent open/close of the file releases any/all locks on it.

    This is currently in an !BSD block, which appears to include macOS, but
    macOS *does* support OFD locks, so I'll be fixing that here shortly.

    ---
    ■ 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 Wed Dec 4 18:48:28 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/6000b7606167fe18b73d63a7
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Clean up the OFD check/decision, make use of fcntl() locks easier to opt-in

    ---
    ■ 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 Thu Dec 5 17:10:10 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/c88cfcedf21c1c9dd6bbeb97
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Fix typo in Windows version of xp_lockfile()

    ---
    ■ 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 Thu Dec 5 17:16:34 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/c2f0aded1f86373335282c2a
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Move the xp_lockfile() into a compile block that includes Borland

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Thu Dec 5 17:32:00 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/f28db0b28d5f5d46c8801526
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Need locking.h here for Borland C++ build

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Thu Dec 5 17:43:13 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/f421f1bb88f20536b2af3d4c
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    In Boland's io.h, this function is just called locking()

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Thu Dec 5 17:53:11 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/fc17319e92c4b7af30123d57
    Modified Files:
    src/xpdev/filewrap.c
    Log Message:
    Appears MinGW requires '_locking' Borland requires 'locking' and MSVC does both

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • 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