A JMeter run aborts with "Cannot write to ... as folder is not empty". What happened?

## What is being checked `-o` is not accepted blindly. JMeter turns the argument into an absolute path and runs a safety check on it before anything else happens, in both report modes — the end-of-run form and report-only generation. Three outcomes: | State of the path | Result | |---|---| | Does not exist | Accepted, as long as the parent directory is writable | | An empty directory | Accepted | | A directory with any file in it | `Cannot write to '<path>' as folder is not empty` | | An existing plain file | `Cannot write to '<path>' as it is an existing file` | The check is strict on purpose. A dashboard is a directory tree of generated pages and JSON data; writing a new one over the remains of an old one would produce a page that mixes two runs, which is far worse than a refusal. ## Why it fails early rather than late The folder is validated while the command line is being processed, before the test plan is loaded and long before the first thread starts. That ordering is the useful part: a nightly job that would have written into yesterday's folder fails in seconds. The alternative — discovering it after the load has finished — would waste the whole run, and that is exactly what happens when you do not pass `-o` at all, because then the only checks are the exporters' own laxer ones, applied at export time: the HTML exporter refuses an existing `index.html`, `content/` or `sbadmin2-*` entry in its default `bin/report-output` folder, and the JSON exporter an existing `statistics.json` in the `report-output` folder its own property names, which is relative to wherever you ran the command. ## The companion rule for the results file A run started with `-e` has a second precondition of the same shape, and the message is different enough to be confusing: ``` Results file:results.jtl is not empty ``` With `-e`, the file named by `-l` must not already exist with content. Appending a second run's samples to yesterday's file would make the dashboard describe both runs at once, so JMeter refuses instead. So a rerun of an unchanged nightly command has two ways to be rejected: the old JTL and the old report folder. ## What -f actually does `-f`, spelled `--forceDeleteResultFile` in long form, takes no argument and clears both obstacles before the test: 1. the folder named by `-o` is deleted recursively and recreated as an empty directory; 2. every results file named by a result collector in the plan — including the one `-l` created — is deleted, and if a delete fails JMeter stops with an error naming the file and whether it was readable and writable. In report-only mode (`-g`), only the first of those applies: the file passed to `-g` is the input and is never touched. The obvious caution is that `-f` is a recursive delete of a path you supplied on a command line, so a mistyped `-o` deletes whatever is at the mistyped path. ## Choosing between -f and a fresh path Both work, and they say different things: - **`-f`** keeps one stable location, which is convenient for a local loop or a workspace that is wiped anyway. It destroys the previous run's output every time. - **A dated folder** such as `reports/2026-09-08/` never collides, keeps history, and needs no destructive flag — at the cost of a path that something has to generate. A reasonable default is a dated results file and a dated report folder for scheduled runs, and `-f` for interactive work where you are re-running the same command repeatedly and do not care about the previous output.