Boundary first: this page covers project directories. Bulk deletion in personal directories like Desktop, Downloads, or Documents is out of scope for direct execution — scan, report, confirm, then act.
Recovery requires something to recover from. The real work is making recoverability a daily fact, not a scramble after the fact.
Three layers, increasing cost
| Layer | How | Recovery time | Covers |
|---|---|---|---|
| Version control | A git repo and committing promptly | Seconds (git restore) | Everything committed |
| Snapshot | tar the directory before a run | Minutes | Uncommitted changes |
| None | Rebuild from memory | Unbounded | Nothing |
A minimal snapshot flow, measured:
tar -czf /tmp/ws-$(date +%H%M%S).tgz -C . --exclude='./.git' . # after the fact tar -xzf /tmp/ws-113045.tgz -C .
Rescuing files git deleted
git statusshows an uncommitted deletion:git restorebrings it back.- A committed deletion:
git checkout HEAD~1 --. - Not even the commit is obvious:
git log --diff-filter=D --name-onlyfinds which one deleted it.
rm'd with no git
- Check the recycle bin — many tools move files there rather than deleting.
- Look for editor or system temp and backup files (
*.bak,~$*, swap files). - If nothing, accept that it is gone. Do not run recovery software writing to the same disk — it overwrites what might still be salvageable.
Turn the lesson into rules
- Every cleanup: list with
findfirst, then delete. Never combine listing and deleting in one command. - Batch deletes of no more than ten, verified after each batch.
- When asking the AI to tidy up, require 'list first and wait for my confirmation' — never 'clean it up'.