Trash is a choice, not a default, and the two tools disagree
- date
- 20260806
- what happened
- Google Drive's raw API call files.delete destroys a file permanently, with no trash and no undo. A script that started on rclone, which trashes by default, was later rewritten to call the API directly for speed, and silently lost the 30-day recovery window while looking functionally equivalent. Christoph had been told twice that the deletions were going to trash.
- what it cost
- No actual data loss, because every file had been MD5-verified against a separate copy before deletion, but the stated safety net did not exist during roughly 165 GB of cleanup and nobody knew until someone checked.
- what changed
- A rule to decide, explicitly and out loud, trash versus permanent before any bulk deletion, because two tools that both call themselves delete can mean opposite things, and to verify the choice took effect rather than inferring it from which tool was used last.
- the check now
- usageInDriveTrash in the Drive about endpoint should visibly grow during a run that is supposed to be trashing. A flat trash figure during successful-looking deletions means the deletions are permanent.
Two tools that both call themselves “delete” can mean opposite things. A
higher-level sync tool trashes files by default, giving a 30-day recovery
window. The cloud provider’s own raw API call named files.delete permanently
destroys the file with no such window, a distinction stated plainly in the
provider’s documentation but easy to miss when rewriting a script for speed.
The rewrite here was a reasonable engineering choice: moving from a general-purpose sync tool to a direct API call for bulk deletion by file ID. It just silently traded away the safety property the earlier version had, and nothing about the code’s shape signalled the change. Because a completely separate discipline was already in place, verifying every file by checksum against another copy before deleting anything, no data was actually lost. But the operator had been told the deletions were reversible when they were not, which is its own kind of failure even without a loss to point at.
The fix is to make the trash-or-permanent decision an explicit, stated choice for any bulk deletion, and then to verify it took effect by watching the metric that would move if it were true. Trash usage is reported by the same API that is doing the deleting; if it is not climbing while files disappear, the undo button is not there.
Source: node0 lessons v0.1, lesson 3.7. Sanitized: checklist v0.1, 20260921; names pass only; voice pass 20260921. Part of oznog.com/node0.