Skip to content

Macos: Operations that result in irreversible data loss must require a confirmation dialog. #2365

Description

@MaximAndreevich

Description

I made a screen recording that appeared to be corrupted.
Several attempts to restore it resulted in an unclear error message ("File already exists").
Then I clicked "Discard" and realized that the file had been permanently deleted.

Additional Context

  • Cap version: - 0.6.0
  • Operating system, version: 26.2 (25C56)
  • Device (optional): Macbook pro M1 16

cap-desktop.log

Additional details from the attached cap-desktop.log (times UTC):

Setup: Studio mode, 38.5-min display recording (14:01:52 → 14:40:24), mic + system audio.
Output folder on an SD card (exFAT) in the built-in card reader: /Volumes/MJ_CAM/cap/.

Timeline

  • 14:40:25 — Recording has fragments queued for finalization - opening editor immediately
  • 14:40:35 — Found 1 fragmented segments ... with estimated duration 0ns (for a 38-min recording)
  • 14:41:42 — finalization fails: Failed to finalize recording: IO error: File exists (os error 17).
    This is the first failure, before any recovery attempt.
  • 14:42 → 14:57 — 7 recovery attempts, all failing with the same File exists (os error 17),
    including after an app restart at 14:53.
  • Each attempt fails almost exactly 60 s after it starts (59.3–59.9 s), every time.
  • After the restart, two recoveries of the same project started 19 s apart
    (14:53:30 and 14:53:49), but only one failure was logged. The other attempt never logged
    success or failure. Concurrent recoveries writing the same output could cause EEXIST by themselves.
  • 14:59:52 — I clicked Discard:
    Discarded incomplete recording: /Volumes/MJ_CAM/cap/... 2026-09-28 04.01 PM.cap
    The whole .cap folder was deleted: not moved to Trash, no confirmation,
    and the log doesn't say what was removed.

Why this matters: the raw data was very likely intact. The mic (audio-input.m4a),
system audio (system_audio.m4a) and the fMP4 video segments (init.mp4 + *.m4s)
had been written continuously for 38 minutes. Only the final remux step failed.
A recovery error turned into total data loss through one click.

Expected

  1. Discard of an unrecovered recording asks for confirmation and moves the project to Trash
    instead of deleting it permanently.
  2. When recovery fails, offer "Show raw files in Finder" / "Export audio only".
  3. The error message names the file that already exists, instead of a bare File exists.
  4. Recovery is idempotent (removes its own partial output before retrying) and
    can't run twice concurrently on the same project.
  5. Discard logs what it deleted (paths, total size).

Storage on an SD card may be a contributing factor (a separate report on recording stalls
is coming), but data loss on Discard shouldn't depend on the storage type.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions