fix #9872: refresh repository lock of an idle mount

[ThomasWaldmann]

Problem

Fixes #9872.

An idle FUSE mount makes no repository calls, so its lock's refresh (which currently only happens on read activity) never runs. After <stale> seconds (30 min by default) the lock expires as stale. A compact can then run and its pack rewrites invalidate the mount's cached pack locations, so subsequent reads fail with ObjectNotFound/PackNotFound (even for chunks that still exist, just moved to a new pack) and the next lock refresh aborts the mount with LockTimeout.

Fix

While mounted, run a background thread that periodically calls repository.info() to keep the lock alive (info() only touches the store every <stale>/2 seconds; the rest are cheap no-ops). This is the same idea borg with-lock already used.

The thread logic is factored into a small reusable LockRefresher class in storelocking.py:

LockRefresher(refresh_callable, sleep_interval=60, lock=None)

It runs a daemon thread that periodically calls refresh_callable (optionally under a caller-supplied lock), stops on LockTimeout (the lock was killed — nothing safe left to do), and on terminate() joins with a 5s timeout so a wedged refresh (e.g. a hung remote-repo request) can't stall shutdown / a FUSE unmount. borg with-lock now uses LockRefresher too, replacing its ad-hoc thread runner.

The refresh thread is started after the possible daemonizing fork() (threads do not survive fork()) and terminated in a finally around the FUSE main loop.

This is applied to both FUSE implementations, which are parallel and selected by BORG_FUSE_IMPL:

• fuse.py (llfuse / pyfuse3)
• hlfuse.py (mfusepy)

Thread safety

The FUSE code is otherwise single-threaded, and borgstore connections are not thread-safe. To keep the refresh thread from racing with the FUSE handlers on the store connection, each mount gets a self._repo_lock that serializes all repository access. It is a reentrant RLock, because a FUSE handler can re-enter it on the same thread: check_pending_archive() holds it and calls _process_archive() → _process_leaf() (hardlink branch) → get_item(), which acquires it again. The LockRefresher is given this same lock.

Guarded repository-access points:

• fuse.py: get_item() → ItemCache.get(), check_pending_archive() → _process_archive(), read() → repository_uncached.get(), and the background refresh → repository.info().
• hlfuse.py: check_pending_archive() → _process_archive() (covers the get_many() in _iter_archive_items()), read() → repository.get(), and the background refresh → repository.info().

fuse.py's module docstring is updated to document this single deliberate exception to the single-threaded invariant.

Tests

• All existing mount_cmds_test.py FUSE tests pass on all backends (they exercise the now-serialized read / lookup / archive-loading paths, and thus the real LockRefresher start()/terminate() lifecycle via the mount daemon).
• Added test_fuse_lock_refresh_calls_repository_info: drives LockRefresher through its real start()/terminate() API in a background thread (bounded by an Event wait + join, so it can't hang) and asserts repository.info() is invoked while the serialization lock is held. It uses a plain threading.Lock (whose .locked() exists on all supported Python versions — RLock.locked() is 3.14+ only).

🤖 Generated with Claude Code