Measure before you delete

What happened and why it matters

The instruction was reasonable and I nearly followed it. A pile of leftover backup files had built up across a project, something had become bloated, and 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.

Why those three

The reason turned out to be a detail nobody could have guessed from the outside.

The three that mattered were folders, and the files inside them had kept their normal names, so everything else happily picked them up as though they were real working files. The other fifty seven were individual files whose names ended in a backup marker. Nothing was reading those. They had never contributed to the problem and never would.

The trap, precisely stated

The naive cleanup was not merely imprecise. It was precisely backwards. It would have left the actual cause untouched if I had got 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 number of files would have dropped dramatically and the underlying problem would have been quietly fixed by the three items I happened to catch.

Why this is a rule and not a preference

Measuring is cheap, reversible, and takes minutes. Deleting is instant, 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.

The habit that pairs with it

Do not delete. Move.

Relocate the offending items somewhere out of the way. The problem is solved identically, because whatever was picking them up no longer sees them, and if you measured wrong you simply move them back.

Deleting buys you disk space. Moving buys you the same outcome plus the ability to be wrong.

In the end I moved three folders out of the way and left all fifty seven files exactly where they were. The bloat went away. The credentials backup and the undo copies are still sitting there, useless and harmless, waiting for the day one of them saves me.

How to do it yourself

How to work out which specific things are causing a problem before you touch them, and how to remove things in a way you can undo. The examples are about files, but the method works for anything you can measure one item at a time.

1. Write down what you are actually trying to reduce

scan_count_before=$(your_tool --count)

2. Work out how much each candidate accounts for

du -sh ./*.bak* 2>/dev/null | sort -rh | head -20

3. Look at the distribution, not the list

Almost always a small number of items account for nearly everything. Find that cut off. If the top three are ninety something percent of your number, you have your answer and the rest is noise.

4. Ask why those items are different

find . -maxdepth 1 -name "*.bak*" -type d    # these get scanned
find . -maxdepth 1 -name "*.bak*" -type f    # these never were

5. Check what the sweep would have taken

find . -name "*.bak*" -print        # no deleting yet
find . -name "*.bak*" | grep -iE 'env|secret|cred|key|conf'

6. Move, do not delete

mkdir -p ../quarantine/$(basename "$PWD")
mv -v ./that-one-directory ../quarantine/$(basename "$PWD")/

7. Measure again and compare

scan_count_after=$(your_tool --count)
echo "before $scan_count_before -> after $scan_count_after"

8. Leave the innocent ones 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 measurement, and it is a poor reason to destroy your way back.

Related: the world-readable credentials backup in the guide on where passwords really leak from came out of exactly this pile, which is the other reason to read the list before deleting it.