138.filesystem lock by crwood · Pull Request #141 · gridsync/gridsync

Conversation

@crwood

A fix/workaround for the issue described in #138: rather than listening on port 52045 to provide a quick-and-dirty interprocess mutex that works across platforms, this PR instead leverages the python standard library's fcntl.flock() to provide a filesystem-based exclusive locking mechanism on UNIX-like systems (falling back to keeping an open file descriptor on Windows to provide similar -- but not wholly equivalent -- functionality), thereby preventing the situation in which Gridsync would sometimes erroneously throw a user-facing "Gridsync is already running" error message on certain macOS Mojave configurations (caused, it seems, from security/sandbox policies that might prevent listening/binding on ports).

As this can't be relied upon for cleanup; acquire should not rely on the
lockfile not existing
Otherwise, the destination directory of the lockfile may not exist.

@crwood crwood deleted the 138.filesystem-lock branch

January 19, 2019 20:59

1 participant

@crwood