Measure before you delete
The instruction was reasonable and I nearly followed it. A pile of leftover backup files had built up across a project and something downstream had gotten bloated, so the obvious move was to clear them out. Roughly sixty items. A single command would have done it.
Instead I spent ten minutes measuring which of them were actually causing the problem. The answer was three. Not three categories. Three items, out of about sixty, were responsible for all of it.
The reason turned out to be a detail nobody could have guessed from the outside. The three that mattered were directories, and the files inside them had kept their normal extensions, so everything downstream happily picked them up as if they were real source files. The other fifty-seven were individual files whose names ended in a backup suffix. Nothing was reading those. They had never contributed to the problem and never would.
What the obvious sweep would have destroyed. Among those fifty-seven innocent files: a backup of a credentials file, and a stack of rollback copies of a script I had been carefully revising all week. The exact things you want during an incident. All deleted, for no benefit, in pursuit of a problem they were not causing.
That is the trap. The naive cleanup was not just imprecise, it was precisely backwards. It would have left the actual cause untouched if I had gotten the pattern slightly wrong, while destroying the safety net I would need the next time something broke. And it would have looked like a success, because the file count would have dropped dramatically and the underlying problem would have been quietly fixed by the three items I happened to catch.
Think of a doctor treating pain by removing everything in the general area. The pain probably stops. So does a lot of other useful function, and nobody learns anything about what was actually wrong.
The asymmetry is what makes this a rule rather than a preference. Measuring is cheap, reversible, and takes minutes. Deleting is instantaneous, feels productive, and cannot be undone. When one option is cheap and reversible and the other is fast and permanent, do the cheap reversible one first, every time. You will occasionally waste ten minutes. You will never lose the file you needed.
There is a second habit that pairs with it, and it costs nothing. Do not delete. Move. Relocate the offending items somewhere outside the scope of whatever is picking them up. The problem is solved identically, because the thing scanning no longer sees them, and if you measured wrong you simply move them back. Deletion buys you disk space. Relocation buys you the same outcome plus the ability to be wrong.
In the end I moved three directories out of scope and left all fifty-seven files exactly where they were. The bloat went away. The credentials backup and the rollback copies are still sitting there, useless and harmless, waiting for the day one of them saves me.
Measure what is actually costing you before you remove anything. The obvious cleanup is usually the wrong one.
How to attribute a problem to specific items before you touch them, and how to remove things reversibly. The examples are disk and file-count shaped, but the method works for anything you can measure per item.
1. Write down what you are actually trying to reduce
Not "clean up the old files." Name the measurable thing: disk used, items being scanned, time a job takes. If you cannot name a number, you cannot tell afterwards whether you helped.
# target: the scan picks up 4,000 things and should pick up far fewer
# baseline BEFORE touching anything:
scan_count_before=$(your_tool --count)2. Attribute the metric per candidate
For each thing you were about to delete, work out how much of the metric it accounts for. Sort descending. This is the whole technique and it usually takes one command.
# biggest contributors first, so you can see the real distribution
du -sh ./*.bak* 2>/dev/null | sort -rh | head -20
# or, when the metric is "things a tool indexed":
your_tool --list | awk -F/ '{print $1}' | sort | uniq -c | sort -rn3. Look for the distribution, not the list
Almost always a small number of items account for nearly everything. Find that cut. If the top three are ninety-something percent of your metric, you have your answer and the rest is noise.
# typical result: 3 of 60 items = essentially all of the problem
# the other 57 contribute nothing measurable4. Ask why those items differ
Do not stop at which. Understanding why the guilty ones are guilty tells you whether the pattern will recur. In my case: directories get walked into and their contents keep normal extensions, individual files with a backup suffix are skipped entirely.
# the distinguishing property, once you look:
find . -maxdepth 1 -name "*.bak*" -type d # these get scanned
find . -maxdepth 1 -name "*.bak*" -type f # these never were5. Check what the sweep would have taken
Before running any destructive command, list exactly what it would touch and read that list properly. Look for credentials, backups of live config, and recent rollback copies.
# dry run FIRST, and actually read the output
find . -name "*.bak*" -print # no -delete yet
find . -name "*.bak*" | grep -iE 'env|secret|cred|key|conf'6. Move, do not delete
Relocate the guilty items outside the scanned area, preserving structure and permissions. Same result, fully reversible. Use a tool that copies metadata rather than a plain move if you are crossing filesystems.
mkdir -p ../quarantine/$(basename "$PWD")
# move only the measured offenders, one at a time, verifying each
mv -v ./that-one-directory ../quarantine/$(basename "$PWD")/7. Re-measure and compare against the baseline
Run the same count you took in step one. If the number did not move the way you predicted, your attribution was wrong, and now you can put everything back because you moved instead of deleting.
scan_count_after=$(your_tool --count)
echo "before $scan_count_before -> after $scan_count_after"8. Leave the innocents alone
Resist tidying the fifty-seven. They cost you nothing and one of them is the file you will want at two in the morning. Tidiness is not a metric, and it is a bad reason to destroy a rollback path.
Related: the world-readable credentials backup in the secrets log came out of exactly this pile, which is the other reason to read the list before deleting it.