[echoix]

Description

Extracts and reworks one self-contained change out of upstream PR
OSGeo/grass#2616 ("CI: Address
Windows specific issues in testsuite", open since 2022, 35 commits, by
Stefan Blumentrath / @ninsbl) so it can be evaluated on its own. Opened
against this fork, for testing, not upstream.

raster/r.mfilter/testsuite/test_r_mfilter.py creates its filter-definition
temp file with tempfile.NamedTemporaryFile() and keeps it open (via
.name) while r.mfilter opens the same path again. On Windows this second
open fails, because Windows does not allow reopening a file that another
handle (here, the still-open Python file object) has locked. That's why all
6 tests in this file carry @xfail_windows. #2616 replaces this with
grass.script.tempfile(create=False), which only reserves a unique path (via
g.tempfile -d) without holding it open, then writes to it directly.

Motivation and context

An AI (Claude) review of #2616 in July 2026, and a second one now, flagged
this as the easiest individual piece of that PR to land as its own, minimal
PR: it is confined to one test file, has a well-understood, verifiable root
cause (the double-open bug is exactly what @xfail_windows's own docstring
describes), and doesn't depend on any of the PR's other, more invasive
Windows changes.

That said, #2616's own diff for this file is not usable as a straight
cherry-pick: it was branched in 2022 and never rebased, so its diff against
current main also reverts changes unrelated to the tempfile fix that
landed on main in the meantime — a docstring correction
(nc_spm_full_v2alphav2 -> nc_spm_full_v2beta1), tightened variance
reference values, and trailing-whitespace cleanup. This PR re-implements
just the tempfile fix against current main, so none of that unrelated
history gets clobbered. It also drops filter.close() (no longer needed,
since filter is now a path string, not a file object) and the
@xfail_windows markers themselves, per the instruction in
xfail_windows's own docstring: "Once the test is fixed and passing, remove
the decorator."

I have not verified this on an actual Windows machine. If the Windows CI job
here still fails, the @xfail_windows markers should be restored, and the
underlying reasoning re-examined — the AI analysis should not be taken as
proof the fix works, only as a plausible, checkable hypothesis.

How has this been tested?

• python3 -m py_compile on the changed file.
• ruff check --preview and ruff format --diff (both clean, ruff 0.15.17
  to match .pre-commit-config.yaml).
• Not run against a live GRASS build or on Windows (no build available in
  this environment) — relying on this fork's CI to confirm the fix on
  Windows and non-regression on Linux/macOS.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing
  functionality to not work as before)

Checklist

• PR title provides summary of the changes and starts with one of the
  pre-defined prefixes
• My code follows the code style
  of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes. (No new tests added; existing
  tests in this file are what the change fixes and un-xfails.)

---

Original fix idea from Stefan Blumentrath (@ninsbl) in
OSGeo/grass#2616, reworked here
against current main. AI-assisted (Claude) analysis and implementation;
please verify independently before relying on this, especially the removal
of the @xfail_windows markers.

Generated with Claude Code (sonnet 5)

[echoix]

On my fork, the tests of this PR passed on windows, 351 files passing, 8 failed. The r.mfilter test passes.

[ninsbl]

Looks good to me.