FileMonitor

DogmaDragon · October 27, 2026, 4:07pm

FileMonitor: fix macOS shared-memory name exceeding shm_open limit

main ← phildapunk:fix/filemonitor-macos-shm-name-too-long

opened 06:58PM - 24 Oct 26 UTC

Fixes #801. ### The problem `Start Library Monitor Service` has never actually… started the background service on macOS. The service's running/singleton lock is a POSIX named shared-memory segment: ```python SHAREDMEMORY_NAME = "DavidMaisonaveAxter_FileMonitor" # 31 chars ``` macOS's `shm_open()` rejects names longer than `PSHMNAMLEN` (31 chars, *including* the leading `/` that `multiprocessing.shared_memory` prepends on POSIX). This name is exactly 31 characters, so with the slash it's 32 — one over the limit: ``` >>> from multiprocessing import shared_memory >>> shared_memory.SharedMemory(name="DavidMaisonaveAxter_FileMonitor", create=True, size=10) OSError: [Errno 63] File name too long: '/DavidMaisonaveAxter_FileMonitor' ``` The `except:` around that call swallows the exception and logs a generic "must already be running" message, so the real cause never showed up in the log — just the same misleading line on every attempt, for well over a year of this user's `filemonitor.log` history. ### What this does - **Shorten `SHAREDMEMORY_NAME`** to 26 characters. Verified empirically on current macOS that 30 chars succeeds and 31 fails, so this has headroom. - **Log the real exception** in the existing error message, so if this ever regresses (e.g. a future rename back over the limit) it's visible instead of misdiagnosable. - **Harden `executeProcess()`'s detach path**, shared byte-for-byte across `FileMonitor`, `DupFileManager`, and `RenameFile`'s `StashPluginHelper.py`: pass `start_new_session=True` when detaching, so the spawned child survives the launching task process exiting. The code already carried a comment flagging this was needed on macOS (`# On detach, may need the following for MAC OS ... start_new_session=True`) but never applied it. ### Testing Against a live Stash instance running natively on macOS (not Docker): - **Before**: clicking "Start Library Monitor Service" logged a spawned pid and "transitioning to service mode", but `Settings → Tools → FileMonitor` immediately reported `FileMonitor is NOT running!!!` — reproduced on every attempt. - **After**: reproduced the exact `OSError` directly against `multiprocessing.shared_memory` with the old name, confirmed the new name succeeds up to 30 chars, applied the fix, reloaded the plugin in Stash, started the service, and confirmed `Settings → Tools → FileMonitor` now reports **running**. ### Scope Only touches `filemonitor.py`'s shared-memory name/error message, and the identical `executeProcess()` block in all three vendored `StashPluginHelper.py` copies. Bumped each plugin's version (`FileMonitor` 1.0.7→1.0.8, `DupFileManager` 1.0.2→1.0.3, `RenameFile` 1.0.4→1.0.5) since `StashPluginHelper.py` changed in all three, and added a FileMonitor version_history entry. ### LLM-assisted contribution disclosure Per the repository's contribution policy: this change was prepared with LLM assistance (Claude). The diff has been reviewed by me, the testing described above was carried out and its results are reproduced verbatim, and I take full responsibility for the change and its license compliance.

@David-Maisonave would you be interested in reviewing it?