Skip to content

fix(fqn): cap derived project-name length to avoid ENAMETOOLONG#745

Merged
DeusData merged 1 commit into
mainfrom
fix/project-name-length-cap
Jul 1, 2026
Merged

fix(fqn): cap derived project-name length to avoid ENAMETOOLONG#745
DeusData merged 1 commit into
mainfrom
fix/project-name-length-cap

Conversation

@DeusData

@DeusData DeusData commented Jul 1, 2026

Copy link
Copy Markdown
Owner

Distilled from #624 (thanks @mvanhorn for the ENAMETOOLONG catch).

The genuinely-missing piece: cbm_project_name_from_path hex-encodes non-ASCII path bytes (#571, already on main) but has no length cap — a deep CJK / non-ASCII path triples in length past the filesystem's 255-byte filename-component limit, so <cache>/<name>.db becomes un-openable (ENAMETOOLONG).

Fix: cap the derived name at FQN_MAX_NAME_LEN (200). Names within the cap are returned unchanged (no drift for already-indexed projects); a longer name keeps its first (CAP−9) bytes + an FNV-1a hash of the full name as a -%08x suffix so distinct long paths stay distinct. The hex encoding scheme is unchanged — added on top, avoiding the name-drift that swapping schemes would cause.

Reproduce-first: project_name_length_capped_issue624 — deep CJK path (~376-byte raw name) → asserts result ≤ 200, validator-safe, and two long paths differing only in the trailing segment get different names; a short CJK path stays byte-identical (no drift). RED (376 > 200) → GREEN. Full suite 5738/0.

Supersedes the useful part of #624, which otherwise conflicts with main and would have swapped the encoding scheme (causing project-name drift). Co-authored with @mvanhorn.

cbm_project_name_from_path hex-encodes non-ASCII path bytes (#571), but had no
length cap -- a deep CJK / non-ASCII path triples in length past the
filesystem's 255-byte filename-component limit, so <cache>/<name>.db becomes
un-openable (ENAMETOOLONG).

Cap the derived name at FQN_MAX_NAME_LEN (200): names within the cap are
returned UNCHANGED (no drift for already-indexed projects), while a longer name
keeps its first (CAP-9) bytes plus an FNV-1a hash of the full name as a "-%08x"
suffix, so distinct long paths stay distinct. The hex encoding scheme is
unchanged.

Distilled from #624 by Matt Van Horn (the ENAMETOOLONG catch); the rest of that
PR was redundant with the #571 fix already on main and would have swapped the
encoding scheme, causing project-name drift.

Reproduce-first: project_name_length_capped_issue624 builds a deep CJK path
(~376-byte raw name) and asserts the result is <= 200, validator-safe, and that
two long paths differing only in the trailing segment map to different names; a
short CJK path stays byte-identical (no drift). RED (376 > 200) -> GREEN. Full
suite 5738/0.

Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
Co-Authored-By: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
@DeusData DeusData added bug Something isn't working ux/behavior Display bugs, docs, adoption UX priority/high Needs near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker. labels Jul 1, 2026
@DeusData
DeusData merged commit c9dd016 into main Jul 1, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working priority/high Needs near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker. ux/behavior Display bugs, docs, adoption UX

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant