Problem
EverOS (everos/core/persistence/locking.py:13) imports fcntl at module top, which is POSIX-only. On native Windows, everos server start crashes with ModuleNotFoundError: No module named 'fcntl'.
Current state (after #170)
- Raven side: platform guard added -- onboard skips memory config on win32,
backend.start() degrades to NoOpAdapter with a warning. Users are guided to WSL.
- EverOS side: upstream declares "Windows is not supported" in docstring. The
win_fcntl_shim in Raven's embedded mode used to paper over this, but HTTP-only mode spawns a child process where the shim has no effect.
Impact
Windows users get no EverOS memory at all (no episodes, profiles, skills, recall). Native Markdown memory (MEMORY.md) still works.
Possible fixes
- EverOS upstream: replace
fcntl with portalocker (or equivalent) in everos/core/persistence/locking.py -- same approach Raven took in raven/utils/portable_lock.py
- Raven workaround: inject
win_fcntl_shim into the spawned subprocess environment before everos server start (fragile, depends on everos internals)
- Accept and document: Windows users use WSL (current state)
Option 1 is the clean fix but requires an everos release.
Evidence
everos==1.1.3, everos/core/persistence/locking.py:13: import fcntl
- Raven guard:
raven/plugin/memory/everos/backend.py (win32 check in start())
- Raven guard:
raven/cli/onboard_commands.py (win32 check in step 4)
Problem
EverOS (
everos/core/persistence/locking.py:13) importsfcntlat module top, which is POSIX-only. On native Windows,everos server startcrashes withModuleNotFoundError: No module named 'fcntl'.Current state (after #170)
backend.start()degrades to NoOpAdapter with a warning. Users are guided to WSL.win_fcntl_shimin Raven's embedded mode used to paper over this, but HTTP-only mode spawns a child process where the shim has no effect.Impact
Windows users get no EverOS memory at all (no episodes, profiles, skills, recall). Native Markdown memory (
MEMORY.md) still works.Possible fixes
fcntlwithportalocker(or equivalent) ineveros/core/persistence/locking.py-- same approach Raven took inraven/utils/portable_lock.pywin_fcntl_shiminto the spawned subprocess environment beforeeveros server start(fragile, depends on everos internals)Option 1 is the clean fix but requires an everos release.
Evidence
everos==1.1.3,everos/core/persistence/locking.py:13:import fcntlraven/plugin/memory/everos/backend.py(win32 check instart())raven/cli/onboard_commands.py(win32 check in step 4)