FR: concurrent access from multiple machines

[bakhtiyarneyman]

The README outlines that concurrent access is not supported yet. Here's an issue to track interest/stimulate discussion about potential solutions.

[bakhtiyarneyman]

This is a very naive sketch of a possible solution that's intended as a conversation starter. I don't have the expertise on fuse/platform specifics to assert that this is feasible.

• There is a service that manages leases for cryfs processes running concurrently on different machines.
  • Something like firebase + firestore could work.
    • They offer 50k reads/day as part of their free-tier.
      • If each user is responsible for their own firebase account there is no centralized entity that needs to front the bill and manage payments.
      • A centrallized SaaS service is also possible.
    • They provide C++ SDK.
• The directory is mounted on each machine
  • With rw access when there are no leases, or if this machine has the lease.
  • With ro access if there is an outstanding lease, and this machine doesn't have it.
• Whenever a user attempts to write to the mounted directory,
  • The cryfs process tries to obtain a lease from the service.
  • If the lease can't be obtained the operation errors out. (Will async writes be a problem?)
  • If the lease is obtained, all cryfs processes except one receive a message on their subscription and switch the directory to read-only mode. (Is it even possible?).
  • The lease is delimited in time and automatically expires, unless explicitly renewed by the process that currently has the write access. cryfs renews the lease if there has been a write in the last N seconds. (This precludes fairness, which I suspect is not important for this problem).
  • The cryfs processes switch the mounted directory from ro to rw once the lease expires. (Is this possible?)
• The above would probably work if the synchronization client (such as onedrive) could provide guarantees that it would write data within a deterministic horizon, which matches the lease expiration interval. But it is way too optimistic (e.g. network failures, client errors etc.)
  • One idea is to set up a separate fuse directory for the sync client to write into/read from. That way we could guarantee that the synchronization client doesn't write at the same time as the cryfs process. cryfs could serve as multiplexer of writes to the underlying storage between the sync client and the local user.
  • When a merge conflict is detected, cryfs process could refuse to proceed further until the merge conflict has been resolved manually. (How to handle partially completed syncs?)

A big question is if all of the above should be done as part of cryfs, or cryfs should be extended to communicate with a process that manages leases. Then alternative implementations would be possible.