Path recovery plans: validate where paths end up, and make every suggested name valid #149

New Issue

2026-11-10T20:01:51Z

james.maes commented

2026-11-10 20:01:51 +00:00

Problem

Two defects in how rename choices for Windows-invalid paths are prepared before they reach the engine:

The Resolve dialog rejects a valid plan when a renamed folder contains a renamed entry. For logs/12:00/run:1.log the rows are logs/12:00 -> logs/12_00 and logs/12:00/run:1.log -> logs/12:00/run_1.log. The pre-flight check validates the second replacement as written, sees the original 12:00 in it, and refuses; no edit to the row can satisfy it, only skipping the file.
--sanitize-paths trusts the suggested names without checking the result. Two paths can be given the same suggestion (a:b and a?b both become a_b), and some suggestions are themselves invalid (x?. becomes x?). The repository then fails with "path sanitization failed".

Scope

PathRecovery.EffectivePathOf: where a path ends up once the renames of it and of its parent folders are applied (or nowhere, when it or a parent is skipped). One definition, used by the pre-flight and by the automatic plan.
The pre-flight validates effective paths.
Every suggested name the validator gives is itself valid.
The automatic plan (moved next to the planner, so the CLI and the app can share it) skips what its renames cannot place.

Acceptance

Tests for the nested case, for colliding suggestions, and that every suggestion validates. 100% line coverage holds; zero warnings; format clean.

## Problem Two defects in how rename choices for Windows-invalid paths are prepared before they reach the engine: - **The Resolve dialog rejects a valid plan** when a renamed folder contains a renamed entry. For `logs/12:00/run:1.log` the rows are `logs/12:00` -> `logs/12_00` and `logs/12:00/run:1.log` -> `logs/12:00/run_1.log`. The pre-flight check validates the second replacement as written, sees the original `12:00` in it, and refuses; no edit to the row can satisfy it, only skipping the file. - **`--sanitize-paths` trusts the suggested names without checking the result.** Two paths can be given the same suggestion (`a:b` and `a?b` both become `a_b`), and some suggestions are themselves invalid (`x?.` becomes `x?`). The repository then fails with "path sanitization failed". ## Scope - `PathRecovery.EffectivePathOf`: where a path ends up once the renames of it and of its parent folders are applied (or nowhere, when it or a parent is skipped). One definition, used by the pre-flight and by the automatic plan. - The pre-flight validates effective paths. - Every suggested name the validator gives is itself valid. - The automatic plan (moved next to the planner, so the CLI and the app can share it) skips what its renames cannot place. ## Acceptance Tests for the nested case, for colliding suggestions, and that every suggestion validates. 100% line coverage holds; zero warnings; format clean.

james.maes added the bug quality labels 2026-11-10 20:01:51 +00:00

james.maes referenced this issue from a commit

2026-11-10 20:19:26 +00:00

fix(recovery): plans are checked by where paths end up; suggestions are valid

james.maes referenced a pull request that will close this issue

2026-11-10 20:19:26 +00:00

fix(recovery): plans are checked by where paths end up; suggestions are valid #150

james.maes referenced this issue from a commit

2026-11-10 20:53:38 +00:00

fix(recovery): folders by original path, linear cost, one policy for clashes

james.maes referenced this issue from a commit

2026-11-10 20:53:40 +00:00