Summary
On Windows, a targeted index --files update can accept an 8.3 short-name spelling of a file or child directory, then persist that lexical short path as a second indexed row instead of matching the long-name row created by a full scan.
For example, after a full scan indexes LongDirectoryName/app.cs, a targeted update through an available short alias such as LONGDI~1/app.cs can address the same physical file while carrying a different relative path into update-target and database identity handling.
Expected behavior
Native aliases that resolve to the same selected file should update the existing canonical indexed path. They must not create two rows for one physical file or leave the long-name row stale.
Distinct files and hardlinks should retain their existing path-based semantics; the fix should not collapse different directory entries solely because they share a file identity.
Suggested regression coverage
- On an NTFS volume with 8.3 aliases enabled, create and fully index a long directory/file path.
- Modify the file and run
index --files through its short-name spelling.
- Verify the long canonical row is updated and no short-name row is added.
- Cover a short project-root alias and a short child-directory alias separately.
- Preserve distinct hardlink paths and case-sensitive-directory behavior.
Likely areas include targeted update normalization and indexed-path membership/canonicalization after path filtering has accepted the native alias.
Scope note
This pre-existing behavior was identified while auditing #5091. That issue validates explicit selections atomically but does not redefine the canonical database path used for a single accepted Windows alias.
Summary
On Windows, a targeted
index --filesupdate can accept an 8.3 short-name spelling of a file or child directory, then persist that lexical short path as a second indexed row instead of matching the long-name row created by a full scan.For example, after a full scan indexes
LongDirectoryName/app.cs, a targeted update through an available short alias such asLONGDI~1/app.cscan address the same physical file while carrying a different relative path into update-target and database identity handling.Expected behavior
Native aliases that resolve to the same selected file should update the existing canonical indexed path. They must not create two rows for one physical file or leave the long-name row stale.
Distinct files and hardlinks should retain their existing path-based semantics; the fix should not collapse different directory entries solely because they share a file identity.
Suggested regression coverage
index --filesthrough its short-name spelling.Likely areas include targeted update normalization and indexed-path membership/canonicalization after path filtering has accepted the native alias.
Scope note
This pre-existing behavior was identified while auditing #5091. That issue validates explicit selections atomically but does not redefine the canonical database path used for a single accepted Windows alias.