The comment character hiding at the front of a folder name
- date
- 20260806
- what happened
- An rclone --files-from list treats any line starting with # as a comment and silently skips it, still exiting 0. A directory-naming convention here puts # at the front of top-level folders, and a cloud-storage cleanup wrote paths relative to each subtree, so many lines began with that character and were never acted on.
- what it cost
- 1,039 of 4,232 intended deletions silently did not happen, with rclone reporting success on every tree. Caught only by re-listing the target afterwards and comparing counts.
- what changed
- Paths in any --files-from list are now written from the remote root, so a top-level folder name never begins a line, and a script-level assertion checks that no line starts with # before the file list is trusted.
- the check now
- Never accept an rclone exit code as proof a deletion happened. Re-list the target and compare the asked-for set against the actually-gone set.
A batch file-deletion tool’s list format borrowed a very old Unix convention.
A line beginning with # is a comment, not data. That convention collided
with a personal filing system that prefixes its top-level folders with # for
visual grouping in a file browser. Because the path list was built relative to
each subtree rather than from a common root, many entries legitimately started
with that character, and the tool silently treated roughly a quarter of the
intended deletions as comments, then reported complete success.
The first instinct when investigating was to blame API rate limiting, because
a rate-limit warning happened to be in the debug log at the same time. That
was a coincidence, not the cause, and chasing it wasted time before someone
thought to check the input file for a leading #.
The fix is narrow. Write paths from a root that guarantees no ambiguous leading character, and assert that property before trusting the list. The lesson is broader. Any success signal from a bulk operation tool is a claim, not a proof, and the only thing that actually confirms a destructive operation happened is checking the state it was supposed to change. Here that was one extra listing and a count comparison, which is cheap enough to do every time.
Source: node0 lessons v0.1, lesson 3.6. Sanitized: checklist v0.1, 20260921; folder names removed; voice pass 20260921. Part of oznog.com/node0.