fix(fqn): cap derived project-name length to avoid ENAMETOOLONG#745
Merged
Conversation
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>
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Distilled from #624 (thanks @mvanhorn for the ENAMETOOLONG catch).
The genuinely-missing piece:
cbm_project_name_from_pathhex-encodes non-ASCII path bytes (#571, already onmain) 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>.dbbecomes 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-%08xsuffix 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
mainand would have swapped the encoding scheme (causing project-name drift). Co-authored with @mvanhorn.