Refactor mount drivers around explicit capabilities and a shared lifecycle #59

New issue

Open

opened 2026-04-11 15:44:01 +00:00 by glenux · 0 comments

glenux commented

2026-04-11 15:44:01 +00:00

Owner

Summary

Introduce a generic mount/unmount execution pipeline driven by explicit driver capabilities, and centralize alias/symlink lifecycle management.

This issue is a follow-up / architectural extension around #58 (kio-fuse support).

Why

Current drivers in src/models/* do not expose their behavior explicitly. Instead, behavior is split between:

shared generic logic in src/models/concerns/base.cr
driver-specific logic in each *_config.cr
KIO-specific lifecycle logic embedded directly in src/models/kio_fuse_config.cr

This creates an inconsistency:

gocryptfs, sshfs, httpdirfs rely on Concerns::Base
kio-fuse bypasses Concerns::Base and implements its own mount / unmount / mountpoint lifecycle
alias/symlink creation and cleanup exist only in KIO and are not modeled as part of a generic mount workflow

Proposal

Define an explicit driver behavior contract and refactor the current mount lifecycle around a shared coordinator.

Scope

Each driver exposes its behavior instead of deciding execution flow internally
Mount / unmount orchestration is centralized as much as possible
Alias/symlink creation and cleanup are centralized too
Driver-specific overrides remain possible when strictly required

Relevant files

src/models/abstract_filesystem_config.cr
src/models/concerns/base.cr
src/models/gocryptfs_config.cr
src/models/sshfs_config.cr
src/models/httpdirfs_config.cr
src/models/kio_fuse_config.cr
src/utils/dbus.cr

Expected outcome

clearer and inspectable driver capabilities
consistent mount/unmount behavior across drivers
KIO integrated as a first-class driver instead of a special-case orchestration path
reusable alias/symlink lifecycle handling

Open questions

How much of mounted? should remain overridable?
What should be the generic alias restoration policy after unmount?
Should KIO unmount remain fusermount -u, or become a backend-specific strategy?

Related to #58

## Summary Introduce a generic mount/unmount execution pipeline driven by explicit driver capabilities, and centralize alias/symlink lifecycle management. This issue is a follow-up / architectural extension around `#58` (`kio-fuse` support). ## Why Current drivers in `src/models/*` do not expose their behavior explicitly. Instead, behavior is split between: - shared generic logic in `src/models/concerns/base.cr` - driver-specific logic in each `*_config.cr` - KIO-specific lifecycle logic embedded directly in `src/models/kio_fuse_config.cr` This creates an inconsistency: - `gocryptfs`, `sshfs`, `httpdirfs` rely on `Concerns::Base` - `kio-fuse` bypasses `Concerns::Base` and implements its own mount / unmount / mountpoint lifecycle - alias/symlink creation and cleanup exist only in KIO and are not modeled as part of a generic mount workflow ## Proposal Define an explicit driver behavior contract and refactor the current mount lifecycle around a shared coordinator. ### Scope 1. Each driver exposes its behavior instead of deciding execution flow internally 2. Mount / unmount orchestration is centralized as much as possible 3. Alias/symlink creation and cleanup are centralized too 4. Driver-specific overrides remain possible when strictly required ### Relevant files - `src/models/abstract_filesystem_config.cr` - `src/models/concerns/base.cr` - `src/models/gocryptfs_config.cr` - `src/models/sshfs_config.cr` - `src/models/httpdirfs_config.cr` - `src/models/kio_fuse_config.cr` - `src/utils/dbus.cr` ### Expected outcome - clearer and inspectable driver capabilities - consistent mount/unmount behavior across drivers - KIO integrated as a first-class driver instead of a special-case orchestration path - reusable alias/symlink lifecycle handling ### Open questions - How much of `mounted?` should remain overridable? - What should be the generic alias restoration policy after unmount? - Should KIO unmount remain `fusermount -u`, or become a backend-specific strategy? ## Related - Related to `#58`