1. Forum
  2. FidoNet
  3. SYNC SYSOPS

  • FILE_RETRY_ERRNO includes EACCES

    From Deucе@1:103/705 to GitLab issue in main/sbbs on Fri Feb 27 10:45:00 2026
    open https://gitlab.synchro.net/main/sbbs/-/issues/1087

    EACCES on FreeBSD at least indicates permissions won't allow you do perform the operation and unlike the others in the macro, there's no implication that trying again later should be expected to work.

    However, I don't really want to poke into `nopen()` behaviour because I have no idea how this behaves on Win32.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Fri Feb 27 16:44:26 2026
    https://gitlab.synchro.net/main/sbbs/-/issues/1087#note_8465

    Looking at [the _sopen() documentation](https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/sopen-wsopen?view=msvc-170), it appears `EACCES` behaves similarly on windows... and also that `EMFILE` should probably be added.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Fri Feb 27 16:46:17 2026
    https://gitlab.synchro.net/main/sbbs/-/issues/1087#note_8466

    Actually it looks like _sopen() doesn't say what happens if the share mode conflicts, so maybe that is EACCES.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Fri Feb 27 16:48:07 2026
    https://gitlab.synchro.net/main/sbbs/-/issues/1087#note_8467

    Yeah, [this page](https://www.itlnet.net/programming/program/Reference/msc/ng46e51.html) says a share mode violation results in EACCES.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Fri Feb 27 16:59:34 2026
    https://gitlab.synchro.net/main/sbbs/-/issues/1087#note_8468

    Yeah, I don't think any of the errno checks were added without reason (e.g. a concurrent access scenario that indicated a retry based on that errno value was needed).

    If you want to take EACCESS out of the conditions for FreeBSD only, I wouldn't have any reason to object or any way test that it caused a regression (e.g. against a Samba share with concurrently opened/locked files).
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab issue in main/sbbs on Fri Feb 27 20:27:39 2026
    close https://gitlab.synchro.net/main/sbbs/-/issues/1087
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Fri Feb 27 20:27:40 2026
    https://gitlab.synchro.net/main/sbbs/-/issues/1087#note_8479

    Nope, since Win32 really does need EACCES in the check, having it just block retrying on other systems is fine.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)