Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#2,365 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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
平均マージ
10時間 44分
マージ済み PR（30日）
88

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CapSoftware/Cap のほかの issue

CapSoftware/Cap の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。