Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
  • 哪裡不對？
#2,365 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
48/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
macos, rust, tauri
領域
desktop

研究方向

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.

由索引模型根據 Issue 內容生成。

描述

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.

主要語言
Rust
星號
22.8k
分支
2k
平均合併
12 小時 41 分鐘
30 天內合併 PR
84

環境準備

  • 提供 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

CapSoftware/Cap 的其他 Issue

查看 CapSoftware/Cap 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。