mxcli new fails with PathTooLongException for deep output paths and leaves partial output

[GG-O-BP]

Summary

mxcli new starts extracting the Mendix blank-project template even when the requested output directory makes one of the template paths exceed MxToolset's supported path length. MxToolset then raises System.IO.PathTooLongException, and mxcli new leaves a partially extracted directory behind without an .mpr file.

Environment

• Observed and reproduced: 2026-08-04
• mxcli --version: mxcli version nightly-20260730-d86fb696 (2026-07-30T05:35:19Z)
• Mendix target / MxToolset: 11.12.0
• OS: Arch Linux, kernel 7.1.5-arch1-2, x86_64
• Filesystem: btrfs (PATH_MAX=4096, NAME_MAX=255)

Scenario and reproduction

From a workspace whose absolute output directory resolves to 99 characters:

mxcli new GlendixVerification \
  --version 11.12.0 \
  --output-dir \
  .codex/artifacts/mxcli-new-verification-mTgn0u/project \
  --skip-init

In my environment that relative path resolved to:

/home/ggobp/Workspaces/mendix/glendix-family/.codex/artifacts/mxcli-new-verification-mTgn0u/project

The result was reproduced twice with independently created output directories.

Expected behavior

Either:

1. create the project at the requested output path, or
2. reject the path before extraction with a concise explanation and a recommendation to use a shorter output directory.

A failed command should not leave an apparently usable but incomplete project directory.

Actual behavior

The template extraction starts and then fails:

Step 2/4: Creating Mendix project 'GlendixVerification'...
Creating project from the 'Blank' template...
Executing step 'Extract package'
Extracting package...
ERROR: System.IO.PathTooLongException: The specified file name or path is too long, or a component of the specified path is too long.
   at Mendix.Modeler.Utility.FileSystem.OpenNewFileForWriting(String filePath)
   at Mendix.Modeler.Packages.PackageExtractor.Extract(...)
   at Mendix.MxToolset.Create.CreateProjectRunner.CreateProject(...)
Error creating project: exit status 1

The command exits with status 1 after partially extracting the project. In one fresh reproduction, the failed output contained:

• 258 files
• 43 directories, excluding the output directory itself
• no GlendixVerification.mpr
• no mprcontents/mprname

Control test

The same command succeeds when only the output path is shortened:

temporary_directory=$(mktemp -d /tmp/mxcli-new-short-XXXXXX)
mxcli new GlendixVerification \
  --version 11.12.0 \
  --output-dir "$temporary_directory/project" \
  --skip-init

That run exited 0, created GlendixVerification.mpr, and wrote GlendixVerification.mpr to mprcontents/mprname.

Boundary verification

I also tested two output directories that differed by one character:

Absolute output-directory length	Longest resulting template path	Result
77	259	success
78	260 (projected from the successful template)	PathTooLongException

The longest template-relative path in the successful Mendix 11.12.0 blank project was:

javascriptsource/nanoflowcommons/actions/node_modules/@react-native-async-storage/async-storage/macos/RNCAsyncStorage.xcodeproj/xcshareddata/xcschemes/RNCAsyncStorage-macOS.xcscheme

This suggests the relevant MxToolset extraction limit is 259 characters for the full destination path, even though the Linux filesystem itself allows substantially longer paths.

Impact

Deep but otherwise valid Linux workspace paths can make mxcli new fail. Because failure occurs after extraction begins, automation must detect and clean up the incomplete output directory before retrying.

Suggested improvement

Before invoking mx create-project, inspect the blank template's maximum relative entry length, or otherwise account for MxToolset's supported destination-path limit. If the requested destination is unsupported:

• fail before creating/extracting files;
• identify the output path as too long;
• recommend a shorter output directory; and
• avoid leaving partial output behind, or remove output created by the failed invocation.

Diagnostic information

mxcli diag --bundle was generated successfully from the short-path control project. The new failure itself occurs before an .mpr exists and did not add a dedicated new session entry, so the command output above is the relevant failure log. Bundle system information:

Version: nightly-20260730-d86fb696
Go: go1.26.5 linux/amd64
Time: 2026-08-04T10:40:14+09:00

[GG-O-BP]

I'm going to take this one and send a fix.

I reproduced it against Mendix 11.12.0 and traced the failure into MxToolset:
its Mendix.Modeler.Utility.FileSystem.OpenNewFileForWriting /
OpenNewTextFileForWriting throw PathTooLongException when the destination
path length is >= 260. This is a hardcoded managed-code check (confirmed by
disassembly), not a Linux filesystem limit — 259 characters succeed, 260 fail.
The same two methods back many MxToolset write paths (package extraction,
native/web export, module import, deployment scripts), so the limit is not
specific to project creation.

I'll pursue the fundamental outcome first: make mxcli new produce a usable
project at the requested output path even when template entries expand past
259 characters, instead of rejecting the path. Because the limit is a managed
check that runs before the OS file API, OS long-path mechanisms (the
LongPathsEnabled registry value, an app-manifest longPathAware, or a
\\?\ prefix) are not expected to bypass it, and I won't patch or redistribute
Mendix binaries. So the feasible route is a contained, atomic short-path /
staging mechanism that keeps the final project valid for later mx check,
mx update-widgets, and MxBuild. If making that robust would require wrapping
every MxToolset operation or otherwise grows disproportionately (e.g. because
other operations still hit the same limit on deeper sub-paths), I'll treat the
fundamental route as infeasible for this issue.

The path-length behavior is platform-sensitive, so every strict path-length
test for the fundamental route will run on native Windows/NTFS (not Linux or
WSL) and the results will be posted to the PR. The matrix: the 259/260 boundary
and paths well beyond it; long-path support OFF vs ON as separate axes at both
layers (HKLM\...\FileSystem\LongPathsEnabled and the process manifest) on a
supported build floor (Windows 10 1607+/Server 2016+) plus one additional
Windows version; ASCII and non-ASCII paths including surrogate-pair characters
(the check counts UTF-16 code units); a subst/junction short-path equivalent;
new vs pre-existing empty output directories; rollback after a forced failure;
and opening, checking, updating widgets, and building the result — asserting the
deepest 260+ character template file exists at the final path and that no
staging/alias path is baked into the .mpr. The PR comment will record the
Windows version/build, both long-path settings, the Mendix/MxToolset version,
the exact tested path lengths, the commands, exit codes, and results.

If the fundamental route proves too large or cannot be applied safely, I'll
fall back to the narrower plan already described here: a version-aware preflight
guard that rejects an unsupported output path before extraction with an
actionable recommendation to use a shorter --output-dir, plus rollback of the
output created by a failed invocation while preserving a pre-existing empty
output directory. That fallback keeps focused coverage for the boundary, new
vs pre-existing output directories, partial-extraction cleanup, and the
user-facing error. I'll link the PR here when it's ready.

[GG-O-BP]

Implementation findings before the PR:

I completed the feasibility work described above. A contained staging/move approach is not safe as a general solution, so the fix uses the documented fallback: a version-aware preflight plus rollback.

Why staging was rejected

Native Windows 11 Home 10.0.26200, Mendix/MxToolset 11.12.2:

• Creating at a short path and moving to an output directory of 100 UTF-16 units (longest template path: 282) produced a project for which mx update-widgets, mx check, and MxBuild deploy all exited 0.
• Moving the same project to an output directory of 180 units (longest template path: 362) still allowed update-widgets and check, but MxBuild deploy failed with PathTooLongException while exporting widgets.
• A subst short alias worked for the tested operations, but relying on it would require every later MxToolset invocation to be wrapped and would make the project location-dependent.

That satisfies the fallback condition from the previous comment: staging can defer the failure, but cannot guarantee a usable project at the requested deep path.

Boundary and Windows long-path matrix

• Output directory 77 units / longest destination 259: project creation succeeded.
• Output directory 78 units / longest destination 260: project creation failed and left partial extraction with no .mpr.
• The 260-unit case failed in all four combinations of LongPathsEnabled 0/1 and process longPathAware OFF/ON. The ON process axis used the signed system dotnet.exe manifest to run mx.dll; the shipped mx.exe manifest has no longPathAware declaration.
• The registry value was restored to its original value (0) after the matrix.

Implemented fallback

• Before extraction, inspect the blank-project ZIP embedded in the exact resolved Mendix version's Mendix.Modeler.Core.dll and calculate its longest destination path in UTF-16 code units.
• Reject a projected path above MxToolset's 259-unit maximum with the measured length and an actionable maximum for a shorter --output-dir.
• On any create/validation failure, remove output created by this invocation. Preserve the identity and emptiness of a pre-existing empty output directory, including a symlinked output.

The scanner was verified against installed Mendix 10.24.9 and 11.12.2 resources; both currently report a longest relative path of 181 UTF-16 units. Tests cover 259/260, surrogate-pair counting, dynamic embedded-template discovery, new/pre-existing output, partial extraction rollback, missing .mpr, symlink preservation, and non-empty output rejection.

Validation completed: go test ./..., go vet ./cmd/mxcli, Windows-target compilation, and git diff --check all pass. I am opening the PR next.

PR: #865