sources/ 存檔沒有大小上限；copy-zotero-attachments 不驗既有 blob 的內容

[kiki830621]

Problem

兩件相關的事：

1. 沒有大小上限：ZoteroStorageFile.read、store-source 與 SourceStore 都把整份檔讀進記憶體，copy-zotero-attachments 的乾跑也一樣。群組 library 的附件可能是別人放進去的。b16v verify 第 15 則。
2. 不驗既有 blob 的內容：copy-zotero-attachments 判斷「已連過」只看 blob 在不在、index 有沒有條目。被截短或換掉的 blob 看不出來，而工具手上其實有 Zotero 的原始位元組可以比對。b16v verify 第 16 則後半。

Type

enhancement

Expected

裁決三件事：

• 要不要設大小上限、上限多少；超過的檔是略過並具名，還是逐塊處理。
• 要不要逐塊算 SHA-256，免得一次整份讀進記憶體。
• 補存路徑要不要順手比對既有 blob 的內容，不一致時怎麼回報。

Actual

以上三件都沒有。

---

Source: b16v verify 修正輪（#606，2026-09-30）

---

Current Status

Phase: verified（R6：HIGH 0、MEDIUM 0）
Last updated: 2026-10-05 by idd-update

Blocking

• （無）待使用者 /idd-close

Commits

• 63037372 feat: sources/ 存檔上限 256 MB、SHA-256 逐塊計算、補存時比對既有 blob (sources/ 存檔沒有大小上限；copy-zotero-attachments 不驗既有 blob 的內容 #703)
• 15f89535 fix: sources/ 逐塊讀取每塊釋放、新連結不連判不出來的存檔、放上位址的退路、殘留暫存檔可見 (sources/ 存檔沒有大小上限；copy-zotero-attachments 不驗既有 blob 的內容 #703)
• 520651e2 fix: sources/ 存檔放上位址不再覆寫、位址被佔住時具名拒絕、重複附件跟著最終結果、訊號清暫存檔 (sources/ 存檔沒有大小上限；copy-zotero-attachments 不驗既有 blob 的內容 #703)
• 3cae9ae4 fix: sources/ 在做不到不覆寫原子放置的磁碟區拒絕存檔，syncFile 不吞真錯誤，訊號清理以名字認暫存檔 (sources/ 存檔沒有大小上限；copy-zotero-attachments 不驗既有 blob 的內容 #703)
• d3d61590 fix: 旗標讀不到時寫入前實際放一次、同步的不支援補三個 errno、possiblyInProgress 判不出時不刪、被推翻的第三條路劃掉 (sources/ 存檔沒有大小上限；copy-zotero-attachments 不驗既有 blob 的內容 #703)
• tag idd-703-verified（e5182cf1）

[kiki830621]

Decision（2026-09-30 14:10 +08:00）

使用者裁決：三件都做，上限 256 MB

• 大小上限 256 MB：超過的檔略過並具名，不截斷。錨點是本機實測（Zotero storage 共 66 MB、最大單檔 5.5 MB），上限約為最大單檔的 46 倍。
• SHA-256 逐塊計算，不再整份讀進記憶體。
• copy-zotero-attachments 補存時比對既有 blob 的內容，不一致時具名回報、不覆寫。

[kiki830621]

Verify R1（2026-09-30）：HIGH 2、MEDIUM 4，修正輪進行中

六席都有結果。本輪與 #697（R2）、#689／#690（R3）同一次驗證，全輪 42 則：HIGH 2（都屬本張）、MEDIUM 8（本張 4、#689 4）、LOW 16、INFO 16。

HIGH

#	席	問題	處置
1、4、6	Codex、requirements、logic	新連結的路徑只處理 .mismatch：位址上是目錄、斷掉的 symlink 或讀不到的檔時照樣連結並回報「已複製」，與「已連過」那條路徑不一致	本輪修正：兩條路徑共用同一個判定，其餘狀態一律拒絕
2、8	devil's advocate、regression	「逐塊雜湊」沒有讓記憶體與檔案大小無關：實測 store-source 尖峰 RSS 約為檔案大小的 2.1 倍，比改動前高；copy-zotero-attachments 會跨檔累積，單檔上限管不到總量	本輪修正：讀取迴圈每一塊都釋放暫存，並補一支在舊程式碼上會紅的記憶體測試；changelog 與文件裡「記憶體與檔案大小無關」的說法一併更正

MEDIUM

#	席	問題	處置
5、9	logic、regression	存 blob 改用 renamex_np(RENAME_EXCL)，在 exFAT／FAT 上每一個新 blob 都失敗，改動前存得進去	本輪修正：不支援獨佔改名時改用其他放置方式，全部不支援時以具名訊息失敗
3	Codex	暫存檔的排除檢查不在批次的前置檢查裡，一批可能寫到一半才被拒	本輪修正：併進前置檢查

LOW 與 INFO

在修正輪一併處理或記下理由，R2 報告逐則對帳。

修正完成、R2 驗過之後再更新這張。

[kiki830621]

Verify R2（2026-10-01）：HIGH 1、MEDIUM 4，進修正輪

六席都有結果。本輪與 #700（R1）、#710（R1）同一次驗證，全輪 51 則：HIGH 1、MEDIUM 5（本張 4、#700 1）、LOW 23、INFO 22。

R1 的兩個 HIGH 已關閉，devil's advocate 席重量過：

• 新連結路徑不再連判不出來的存檔；
• 逐塊讀取壓住了記憶體。

HIGH

#	席	問題	處置
1	Codex	exFAT／FAT 的最後一層退路是 lstat 確認沒有檔、再用一般 rename。兩步之間若有別人放進一個檔，會被覆寫，違反「不覆寫」	改成以 O_EXCL 建立目的檔再串流複製、fsync、驗 digest，不符就刪掉自己建的那個。不再使用會覆寫的 rename。代價寫進誠實邊界：複製期間，未完成的檔在最終檔名下看得到

MEDIUM

#	席	問題	處置
5、6	security、devil's advocate	位址被懸空 symlink 或目錄佔住時，store-source 回報成功、寫 index，但沒存位元組；doctor 也看不到。這是本張引入的回歸：舊版遇到懸空 symlink 會用真檔取代它	writeBlob 的「已經在了」分支先分類位址上的東西：不是一般檔就具名拒絕、不寫 index；doctor 報出位址上不是一般檔的情形
4	logic	只有 copy-zotero-attachments 驗既有 blob；store-source 與 update-entry --add-source 仍信任位址上的任何東西，包括被截短的檔	「已經在了」時比對大小（零成本），不符就具名拒絕；sourcePresence 保留 index 的 bytes 一併比對
2	Codex	內容相同的第二個附件，在第一個真的補存成功之前就報成「已連過」	「已完成」與「待補存」分成兩個狀態，實跑之後才把結果傳給重複附件（LOW 17 同處）

LOW

• 修正輪一起處理：
  • 10、28：doctor 的新鍵要有測試與說明，並附檔案年齡；
  • 12、23：仍有整份讀進記憶體的讀取面，修掉或更正 changelog；
  • 15：訊息指向 doctor，而 doctor 看不到那個狀態——隨 5、6 一起關掉；
  • 20：temporaryToken 要驗形狀；
  • 21：fsync；
  • 22：進行中的暫存檔不要讓健康區塊亮起，以年齡門檻判斷；
  • 24：changelog 措辭；
  • 25：lossless-intake「有界拒絕」的邊界條件要對上本張的逐檔略過；
  • 27：Ctrl-C／SIGTERM 會留下暫存檔，要補清理或寫明。
• 記錄：11——上限實作成 256 MiB（2^28），你的裁決原句是「256 MB」，單位請你確認。

[kiki830621]

Decision（2026-10-02，使用者）：不支援 exFAT／FAT32 這類檔案系統

R3 verify（b26 F6，2026-10-02）在真的 exFAT 磁碟映像上量到：新建檔案的 inode 在第一次寫入後會改變。第三條放置路（檔案系統既不支援 RENAME_EXCL、也不支援 link）靠建立當下的 inode 認自己的檔，所以：

• 失敗清理與訊號清理都失效；
• 讀回驗證抓到的壞檔會留在位址上，之後的 store-source 替它記 index；
• 半截檔會卡住之後的重試。

裁決：拿掉第三條路。 檔案系統不支援「不覆寫的原子放置」時，存檔一律具名拒絕、零寫入，訊息說明要把 store 放在 APFS／HFS+。

live store 在 APFS 上，不受影響。

同輪一起修的另外兩件：

• F_FULLFSYNC 失敗的錯誤被 fsync 的成功吞掉；
• 「大小相同就當作已存在」的判斷與放置中的檔之間有時間窗口。

[kiki830621]

Verify R3–R5（2026-10-02～10-04）：R5 HIGH 0、MEDIUM 0，verified

三輪都是六席交叉驗證（四個 Claude lens、devil's advocate、Codex 跨模型）。表中是 findings 的原始筆數（INFO 不列）；下面把同一件事被多席提出的合併成一條，括號是席數。

輪	HIGH	MEDIUM	LOW	之後的修正
R3	1	6	10	3cae9ae4
R4	0	2	10	d3d61590
R5	0	0	15	—

R3 的 HIGH 與 MEDIUM

• HIGH（devil's advocate）與 MEDIUM（codex、requirements、security、regression，共 5 席）：第三條放置路（exFAT／FAT 上以 O_CREAT | O_EXCL 建目的檔、逐塊複製）靠建立當下取的 (device, inode) 認「自己的檔」。真的 exFAT 映像上量到新建空檔的 inode 是 18446744073709551612、寫入一個位元組後變成 9，所以失敗（ENOSPC、讀回驗證不符、同步失敗）與 SIGINT／SIGTERM 的清理全部比不上，半截檔留在內容位址上；讀回驗證抓到的壞檔下一次存檔還會被當成「已經在了」並記 index；未完成的檔在最終檔名下就看得到，並行的存檔會把大小相同的半截檔當成已存在、之後原作者的清理把它收回——整條拿掉（使用者 2026-10-02 的裁決，binding）：放置只剩 renamex_np(RENAME_EXCL)，不支援時 link(2)，兩者都不支援就在建立任何檔之前具名拒絕、零寫入，訊息說要把 store 放在 APFS 或 HFS+；真的 exFAT 映像上跑真 binary 驗證；訊號清理改成以名字認暫存檔（3cae9ae4）。
• MEDIUM（devil's advocate）：第三條路把 exFAT／FAT 上需要的剩餘空間加倍（暫存檔加目的檔各一份），文件沒寫這個代價——第三條拿掉後兩份的需求一併消失。
• MEDIUM（codex）：syncFile 在 F_FULLFSYNC 失敗時一律退到 fsync，把真的 I/O 錯誤蓋掉；fsync 在 macOS 不清裝置的寫入快取（codex）——只有 F_FULLFSYNC 回「不支援」才退到 fsync，EIO、ENOSPC 等直接回傳、存檔被拒；EINTR 每個呼叫至多重試 8 次（3cae9ae4）。

R4 的 MEDIUM

• 能力旗標讀不到（nil）時，位址上已有同一份內容的存檔不走放置、直接回成功，index 缺那一列時還補一列，「每一次存檔都拒絕」的契約在那裡不成立（codex 席）——改成寫入之前、任何分支之前實際放一次：以 O_EXCL 在同一個分片目錄建一個空探測檔，經同一條放置路放到另一個暫存名，兩個呼叫都回「不支援」就是同一句拒絕，呼叫端什麼都不寫；這一步自己建的目錄在拒絕時收回；Codex 的交叉情境修正前回成功、修正後拒絕，拿掉探測時 3 支測試紅（d3d61590）。
• syncFile 退到 fsync 的條件集合漏了 ENOTTY（regression 席，在掛載的 cd9660 映像上量到）；devil's advocate 指出本機可建立的四種檔案系統（APFS、HFS+、exFAT、FAT32）上 F_FULLFSYNC 都回 0，「可寫而能通過磁碟區閘的檔案系統回 ENOTTY」沒有人證實，後果也只是具名的 fail-closed 拒絕，應算未重現的設計風險——「不支援」改成封閉的六個 errno（加上 ENOTTY、ENODEV、ENOSYS），EIO、ENOSPC、EDQUOT、EROFS 等仍不退；同步失敗的訊息說出 errno 與說明（d3d61590）。

R5

HIGH 與 MEDIUM 皆為 0。LOW 15 條，重點：

• 旗標讀不到時，preflightStoreSource 的 doc 與 copy-zotero-attachments --apply 的說明仍寫無條件的預演保證，程式註解沒寫探測只在寫入時跑（requirements、logic）。
• 旗標讀不到時，「位址上已有同一份」的冪等重存變成寫入路徑，分片目錄不可寫就被拒，訊息還說「沒有存」（security、regression）。
• akashic_store_source 的 MCP 說明沒寫最重要的新拒絕類別：磁碟區做不到不覆寫放置時，每一次存檔都拒絕（requirements）。
• 殘留暫存檔的 possiblyInProgress 與 isStale 拆開之後，App 的提示沒有跟著更新（requirements、logic、regression；devil's advocate 認為「App 沒跟上」說過頭且歸因錯誤）。
• b29 補的兩處沒有測試釘住：分片目錄層的 false? 與訊號登記的撤銷，變異全部存活（devil's advocate）。

LOW 不擋 verified，留給結案時判斷。

逐則處置見 changelog：changelog/2026-10-02-b26-f6-fixes-703-700.md、changelog/2026-10-02-b29-h5-fixes-703-700.md。

[kiki830621]

Decision（2026-10-05，使用者）

akashic_store_source 的 MCP 說明不加「exFAT／FAT32 這類磁碟區上每次存檔都拒絕」那句；拒絕訊息本身會說明原因，說明寫在 CLI help 與文件。

[kiki830621]

Verify R6（2026-10-04）：HIGH 0、MEDIUM 0，維持 verified

R6 是六席交叉驗證（四個 Claude lens、devil's advocate、Codex 跨模型），驗的是 R5 之後只改文字、說明、註解、測試與 App 說明文字的 c86ae785（存檔行為不變）。表中是 findings 的原始筆數（INFO 不列）。

輪	HIGH	MEDIUM	LOW	之後的修正
R6	0	0	0	—

R6

HIGH、MEDIUM、LOW 皆為 0。本輪有兩則 INFO，都是說明文字的精確度，不影響行為：

• copy-zotero-attachments --apply 的說明與 preflightStoreSource 的 doc 說逐筆拒絕進 writeFailed；已連結的 digest 補存失敗實際進另一個清單 restoreFailed，結束碼同為 1，實質正確，用字不精確（requirements 席）。
• akashic_doctor 的說明在改成「後兩列各 20 則」之後，等於明示四個舊陣列完全不截，而它們確實沒有上限（既有行為，不是本次引入）；App 的 strayTemporaryFilesHelp 沒提 300 秒的未來時間容忍（logic 席）。

逐則處置見 changelog：changelog/2026-10-04-b32-f6-fixes-700-703.md（R5 的處置）。