Description
In the compress-before-trash flow, if send2trash succeeds but the subsequent removal
of the original directory fails (permissions, file-in-use, etc.), the error is correctly
raised, caught, and surfaced to the user (item lands in result.failed, printed clearly
in CLI output) — this part already works correctly, no data is lost and nothing is silent.
The actual gap: because the item is in result.failed rather than result.deleted, no
metadata record is written for it. The archive genuinely exists in trash, but devklean history and devklean doctor have no way to know that — from their perspective, nothing
happened.
Proposed fix
This needs a new outcome category on DeleteResult (distinct from success/failure) to
represent "archived successfully, original cleanup failed" — a product/design decision,
not a quick patch, tracked here separately.
Description
In the compress-before-trash flow, if
send2trashsucceeds but the subsequent removalof the original directory fails (permissions, file-in-use, etc.), the error is correctly
raised, caught, and surfaced to the user (item lands in
result.failed, printed clearlyin CLI output) — this part already works correctly, no data is lost and nothing is silent.
The actual gap: because the item is in
result.failedrather thanresult.deleted, nometadata record is written for it. The archive genuinely exists in trash, but
devklean historyanddevklean doctorhave no way to know that — from their perspective, nothinghappened.
Proposed fix
This needs a new outcome category on
DeleteResult(distinct from success/failure) torepresent "archived successfully, original cleanup failed" — a product/design decision,
not a quick patch, tracked here separately.