gocryptfs does not lock the cipherdir exclusively. Two pwrap sessions with different project names but the same [encrypted] cipherdir both mount successfully into their own mount namespaces. Each FUSE daemon has its own cache and writes ciphertext independently → silent cache incoherence and potential ciphertext corruption on concurrent writes (gocryptfs' on-disk format assumes a single writer).
pwrap owns the lifecycle, so it should enforce this itself. Proposal:
- Track mounted cipherdirs in the runtime dir: a lockfile keyed by a hash of the resolved cipherdir path, contents = owning project name + pid.
- On mount, try to acquire the lock. If already held, refuse and exit with a message naming the holding project. Do not prompt — the failure mode is silent data loss, which is exactly when "press Enter to continue" is the wrong default.
- The existing per-project-name lock does not cover this because the key is the project name, not the cipherdir path.
gocryptfs does not lock the cipherdir exclusively. Two pwrap sessions with different project names but the same
[encrypted] cipherdirboth mount successfully into their own mount namespaces. Each FUSE daemon has its own cache and writes ciphertext independently → silent cache incoherence and potential ciphertext corruption on concurrent writes (gocryptfs' on-disk format assumes a single writer).pwrap owns the lifecycle, so it should enforce this itself. Proposal: