Skip to Content
CLIConflicts and recovery

Resolve conflicts and recover work

When another writer changes a file while you edit it, FlashDrive preserves competing work rather than silently overwriting it. Start by checking your mounted drive:

flashdrive mounts

Reconcile a conflict copy

  1. Open the current drive file and its conflict copy.
  2. Compare the changes and save the version you want to keep.
  3. Wait for synchronization, then check flashdrive mounts again.
  4. Remove a redundant conflict copy only after checking that the intended result is saved.

Independent text edits can merge when they affect different parts of a common version. Overlapping edits and binary changes can need a decision. Do not treat the mere presence of both files as a resolved conflict.

Recover unsaved work

The mount stops within about 90 seconds after its connection drops, sometimes sooner. Pending local changes may not yet be on the drive. Keep the recovery files named by the CLI. Once the connection returns, resume the original mount with the same profile and API address:

flashdrive mounts --at ~/FlashDrive/research --resume

Replace ~/FlashDrive/research with the original mount folder. Previously accepted queued changes upload automatically after a successful resume. Reopen files in your applications. If access or a service limit prevents resuming, preserve the drafts and resolve the refusal first. Do not rely on cached reads or local edits after the mount stops.

If the CLI says the mount folder is not empty, follow its instructions to move those files aside, resume, then put them back. These files may have been written after the mount stopped and are not queued uploads. Keep them safe and leave the client’s private recovery data in place. A save while disconnected can fail, so check your application for unsaved work.

Run flashdrive mounts after reconnecting. If it still reports unsaved changes, read the per-file message and resolve the cause before deleting local data or reporting that the cloud copy is current.

Review held deletions

A large removal can be held for confirmation. Use flashdrive mounts to review the exact paths. If you intend those removals, run the exact confirmation command printed for that set. A changed deletion set needs a new confirmation.

Recover a refused direct edit

For an edit or replacement refused because the revision changed, read the latest file, compare it with your intended change, and submit a new edit against that revision. For an accepted upload whose wait timed out, check its status rather than submitting it again.