[armadavalor]

Closes #6710

On Windows, ls with a name that contains * or <, or with a name that is too long, fell into the catch-all error branch and printed the raw io::Error debug output. Now these errors use the same cannot access message as the other errors, with the OS text and without the (os error N) suffix.

Before:

> ls 'a.txtt*'
ls: unknown io error: 'a.txtt*', 'Os { code: 123, kind: InvalidFilename, message: "The filename, directory name, or volume label syntax is incorrect." }'

After:

> ls 'a.txtt*'
ls: cannot access 'a.txtt*': The filename, directory name, or volume label syntax is incorrect.

The exit code is still 2.

The fix is in the IOErrorContext fallback in ls.rs. I replaced ls-error-unknown-io-error with ls-error-cannot-access in en-US and fr-FR. This is not Windows-specific: any other unmapped error now prints like GNU's cannot access ...: <strerror>.

Tests (in tests/by-util/test_ls.rs):

• test_name_too_long, a 300-character name (runs on all platforms)
• test_invalid_filename_windows, a* and a<b (Windows only)

The tests only check the ls: cannot access '<name>': prefix, because the OS message is localized on Windows and differs between libcs.

🤖 Generated with Claude Code

[sylvestre]

on unix, could we check the full message with stderr_is("... File name too long\n")? the prefix check is a bit weak

[sylvestre]

the unknown io error check is redundant with the stderr_contains above, no?

[codspeed]

Merging this PR will degrade performance by 3%

2 warnings, 1 note

⚠️ 124 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

⚠️ Base and head ran on different runner types

Some benchmarks with significant performance changes were compared across different runner types, so the changes might not come from the code. Run base and head on the same runner type, or use CodSpeed Macro Runners for more stable results.

Learn more about Macro Runners

Open the report in CodSpeed to investigate

ℹ️ 1 benchmark has no flamegraph

The flamegraph wasn't generated: most of the time was spent in runtime internals, which would leave nothing useful to analyze.

See affected benchmarks

❌ 1 regressed benchmark
✅ 400 untouched benchmarks
⏩ 70 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Memory	du_all_wide_tree[(5000, 500)]	1,010.5 KB	1,041.8 KB	-3%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing armadavalor:fix-ls-invalid-filename (a4a81c5) with main (1d6ca65)²}

Footnotes

1. 70 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (e90b788) during the generation of this report, so 1d6ca65 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩