Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#2,365 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
macos, rust, tauri
Bereich
desktop

Rechercherichtung

Start with the attached cap-desktop.log and trace the desktop recording recovery and Discard entry points; no source files or tests are named in the issue. Done means failed recovery cannot cause irreversible deletion: Discard is confirmed and moved to Trash, recovery exposes the requested alternatives and error details, retries are safe, concurrent recovery is prevented, and deletion is logged.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug
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.

Vorherrschende Sprache
Rust
Sterne
22.8k
Forks
2k
Ø Merge
12 Std. 41 Min.
Gemergte PRs (30 T.)
84

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus CapSoftware/Cap

Alle Issues in CapSoftware/Cap

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.