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)

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)

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)

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)

close https://gitlab.synchro.net/main/sbbs/-/issues/1087
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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)