FUSE clipboard mount fails on restart: stale mount point not cleaned up

[lamco-office]

Summary

When the server restarts after a crash or unclean shutdown, the FUSE clipboard filesystem mount fails with:

Failed to mount FUSE clipboard filesystem: FileIoError("Failed to create FUSE mount point: File exists (os error 17)")

The server falls back to staging mode, which works but loses the zero-copy file transfer benefit.

Source

Observed during fleet testing on KDE Plasma 6.3.6 (aibox VM). The mount point at /tmp/lamco-rdp-clipboard-* persists after the server exits without cleanup.

Expected behavior

On startup, the FUSE mount code should:

1. Check if the mount point directory already exists
2. If it does, attempt fusermount -u to unmount any stale FUSE mount
3. Remove the stale directory
4. Proceed with fresh mount creation

Current behavior

The code calls std::fs::create_dir() which fails with EEXIST if a previous mount point was not cleaned up. No recovery is attempted.

Impact

File clipboard falls back to staging mode (downloads files upfront instead of on-demand FUSE access). Functional but suboptimal. Users who restart the server frequently will always hit this.

[lamco-office]

Fixed in dev (commit d81215a) — architectural redesign of file transfer subsystem.

The stale mount problem has been resolved structurally, not just patched:

Root cause: FUSE mount used a fixed path ($XDG_RUNTIME_DIR/lamco-clipboard-fuse). On crash, the FUSE daemon dies but the kernel mount persists. On restart, create_dir_all() hits the dead mount and fails with "File exists" (error 17). FUSE falls back to staging mode permanently until manual fusermount -u.

Fix (3 layers):

1. PID-unique mount paths: Each server instance now mounts at $XDG_RUNTIME_DIR/lamco-clipboard-fuse-{PID}. A crashed instance's mount point can never collide with a new instance.

2. Stale mount cleanup on startup: Parses /proc/self/mountinfo for orphaned lamco-clipboard-fuse-* mounts, checks if the PID in the path is still alive (with /proc/{PID}/comm verification to guard against PID recycling), and calls fusermount3 -u on dead ones.

3. Trait-based backend with automatic fallback: File transfer is now abstracted behind a FileTransferBackend trait with FUSE and Staging implementations. If FUSE initialization fails for any reason, the server automatically falls back to the staging backend without user intervention. New file_transfer_mode config option allows forcing a specific backend.

Broader context: This was part of a full file transfer architecture refactoring that extracted ~766 lines from the clipboard manager into a proper module with strategy selection, matching the pattern used by capture and input subsystems throughout the server.

Ships with v1.4.3.