@mgol I don't remember, but below is what I can think of as being potentially of use:

• the unlink means the file won't linger as untracked in the working directory after a test run is done.
• the unlink affects the HTTP status code for requests that are before it is created or after it is emptied (HTTP 404 instead of HTTP 200). Having said that, the JS version never incorporated it, it just returns HTTP 200 always with an empty or non-empty string as response. So presumably our tests are never making the requests too early or too late and not relying on this behaviour?
• the unlink ensures that each test run starts the same way (the file not existing), instead of it being 404 the first test run, but then starting as empty 200 OK the second time.
• the unlink ensures that if something went out of control, or if the writing code uses "append" mode to put content, that it will still start empty instead of growing uncontrolled over time. But.. the empty string overwrite ensures that already.

It doesn't make sense to me why the server would have permission to write the file but not delete it. But, if this helps, then I don't think it's worth further investigating. The only thing I'd recommend is to add it to gitignore (unless it is covered already?) to keep the file out of git-status during development since it's not meant to be committed and wouldn't benefit from a dirty signal there.

@Krinkle the file is actually tracked & in the repo as empty. Which makes me think this unlink never really worked as otherwise finishing a test run with it would create a dirty repository state.

Plus, our tests actually do depend on it existing. That’s why migrating to nginx locally broke some tests for me: some requests for csp.log started returning a 404 instead of 200.

I can make the file untracked but then I have to make sure it exists pretty early somehow.