mirror of
https://github.com/abhigyanpatwari/GitNexus.git
synced 2026-09-08 22:22:52 +00:00
* fix(lib): add stripWindowsLongPathPrefix for path comparisons (#2667) A caller can hand GitNexus a `\\?\`-prefixed path — the usual MAX_PATH workaround on Windows — and `path.resolve` preserves the prefix, so it reaches every string comparison GitNexus keys paths on. It also poisons relativization: `path.win32.relative` cannot express a relative path between a prefixed and an un-prefixed form of the same directory, so it returns the absolute target instead. That absolute string is the shape reported in #2667. The helper is deliberately scoped to the comparison domain. libuv's `fs__capture_path` does not re-add the prefix for over-MAX_PATH paths, so stripping a filesystem-facing path would break long-path access on hosts that have not opted into LongPathsEnabled. `\\?\Volume{GUID}\…` is left alone because the remainder is not a usable path. The test is fixture-free and takes an explicit `platform`, mirroring `normalizeAnalyzerRootPath`, and is registered on the cross-platform matrix since the whole transform is a POSIX no-op. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119fkrRFdQDQKh58LY9Tqh2 * fix(storage): normalize the `\\?\` prefix in canonicalizePath (#2667) `canonicalizePath` is the single comparison key for the repo registry, MCP repo resolution and the server repo routes, and `registryPathEquals` compares its output as a plain string. A caller-supplied `\\?\` prefix therefore matched nothing: a repo registered as `D:\repo` was invisible to a caller passing `\\?\D:\repo`, which surfaces as "repo not found" or a duplicate registration from `analyze`, `remove`, `clean`, the MCP `repo` parameter and the server routes. Both branches are normalized. The realpath branch was already safe — libuv's `fs__realpath` strips the prefix itself — but the `catch` fallback returns `path.resolve(p)` untouched, and that is exactly the branch a path which is not on disk takes. Safe despite the CRITICAL blast radius (27 impacted, 12 direct dependents) because the result is only ever compared, never opened: all 23 call sites feed `registryPathEquals` or a string comparison. Both operands are canonicalized, so the equality relation is preserved and behaviour is unchanged for every un-prefixed input. The two regression assertions run only on windows-latest, where the file already runs via the cross-platform matrix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119fkrRFdQDQKh58LY9Tqh2 * docs(core): correct two false comments about Windows paths (#2667) Both comments assert the opposite of how the platform and the analyzer actually behave, and both would send the next investigator of #2667 the wrong way. `analyzer-identity.ts` claimed the `\\?\` prefix is one that `realpathSync.native` "can emit for paths over MAX_PATH". libuv's `fs__realpath_handle` strips the prefix unconditionally and rewrites `\\?\UNC\` back to `\\`, erroring if neither is present, so realpath never returns one. The prefix can only arrive from caller-supplied input. The optional group in the regex stays as a labelled defensive no-op, and the function's behaviour is unchanged on purpose: these identity fields are compared between an `analyze` and a later `status` run, so this is not the place to reshape a path. `include-extractor.ts` claimed "gitnexus analyze stores absolute paths in the File.filePath column". A full self-index at89bbdcf5had 0 of 239,070 nodes with an absolute or backslash-bearing filePath: File nodes are built from the walker's repo-relative forward-slash paths. The relativization guard below it stays, now described as what it is — a guard against rows this process did not write. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119fkrRFdQDQKh58LY9Tqh2 * test(lib): pin that path.resolve preserves the `\\?\` prefix (#2667) The `canonicalizePath` regression tests for the `catch` fallback can only run on windows-latest, so the fact they rest on is invisible in the Ubuntu suite. Pin it here, in the fixture-free file that runs everywhere: `path.win32.resolve` carries the prefix through untouched, which is all the fallback branch used to do before this fix. Also pins the forward-slash spelling (`//?/D:/…`), which the helper deliberately does not match because `resolve` folds it into the backslash form first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119fkrRFdQDQKh58LY9Tqh2 * fix(lib): match the `\\?\UNC\` token case-insensitively (#2667) The namespace `\\?\` addresses is the Windows object namespace, which is case-insensitive, so `\\?\unc\server\share` is as valid as the uppercase spelling. Matching only `UNC` left the lowercase form prefixed, which is the same registry mismatch #2667 is about, reached through a network share instead of a drive. The drive branch was already case-insensitive (`[A-Za-z]`), so the two branches disagreed with each other. Probed against the built artifact: `\\?\unc\…`, `\\?\Unc\…` and `\\?\UNC\…` now all yield `\\server\share\…`, and `\\?\Volume{…}` is still left alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119fkrRFdQDQKh58LY9Tqh2 * test(storage): guard the canonicalizePath fix on Linux too (#2667) The two `canonicalizePath` assertions in `repo-manager.test.ts` drive the real `realpathSync.native`, so they are `it.skipIf(win32)` and only run on the windows-latest matrix leg. The Ubuntu gate — the one every PR runs — had no coverage of the behaviour at all. This runs the same wiring anywhere by injecting only the platform primitives: `path` becomes `path.win32` (Node's real Windows path implementation, not a stand-in), `realpathSync.native` gets its two actual behaviours (libuv strips `\\?\` for a path on disk, throws ENOENT for one that is not), and the real `stripWindowsLongPathPrefix` is pinned to win32 rather than defaulting to the host. `canonicalizePath` and `registryPathEquals` run unmodified. Pinning the helper is a module mock rather than an override of `process.platform`, which is shared by every test file in a worker. Verified to discriminate: against the pre-fix tree at89bbdcf5it fails 3 of 5, and reverting just the two strip calls on this branch reproduces the same 3 failures with `expected '\\?\D:\Projects\moved-away' to be 'D:\Projects\moved-away'`. The two that pass either way are the realpath branch and the un-prefixed no-op, neither of which ever leaked. Not registered in scripts/cross-platform-tests.ts: it simulates Windows rather than needing it, so its home is the Ubuntu suite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119fkrRFdQDQKh58LY9Tqh2 * fix(lib): require the component that makes a stripped path usable (#2667) Both regexes were under-anchored, so the slice could emit something worse than the input it was handed. `\\?\UNC` has no share to keep and became the bare root `\\`; `\\?\D:foo` is drive-relative and became `D:foo`, which is not absolute and would resolve against the process cwd if a future caller ever passed it to `fs`. `canonicalizePath` previously always returned an absolute path and had stopped doing so. Each pattern now requires the part that makes the remainder a real path — a share name after `UNC\`, a separator after the drive colon. Malformed extended paths are left untouched and simply fail to match a registry entry, which is the safe direction. Also from review: document `\\.\` as a deliberate non-goal alongside `\\?\Volume{GUID}\` (most of what it addresses is not a filesystem path), correct the canonicalizePath docblock, which still claimed entries are canonicalised at write time — `registerRepo` stores `path.resolve` and the paragraph added two lines above says compare-only — and reword the cross-platform registration comment, which claimed the test is only meaningful on windows-latest when every assertion passes an explicit 'win32' and runs identically on Ubuntu. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119fkrRFdQDQKh58LY9Tqh2 * fix(group): keep repo-relative rows in the graph provider strategy (#2667) `extractProvidersGraph` relativised every row with `path.relative(normalizedRepoPath, absolute)`. The rows analyze actually writes are repo-relative — which is exactly what the comment corrected earlier in this branch establishes — and `path.relative` resolves a relative second argument against the PROCESS CWD. So from any cwd other than the repo root, every row came back `..`-prefixed, the containment guard dropped it, and the strategy silently returned [] and fell through to the filesystem fallback. Only absolute rows go through `path.relative` now. The containment guard is unchanged, so foreign and escaping rows are still rejected. Found by three independent reviewers reading the comment this branch corrected and following it to its consequence. The regression test fails without the guard (`expected false to be true`) and passes with it; vitest runs from `gitnexus/`, never the fixture dir, so it exercises the cwd mismatch by construction. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119fkrRFdQDQKh58LY9Tqh2 * test: close the coverage gaps the review surfaced (#2667) Adds the assertions the reviewers named as missing, and corrects one more comment that gave the right conclusion for the wrong reason. analyzer-identity: the comment said the `\\?\` prefix is preserved so the identity fields keep a stable compare shape. That is true but secondary. The load-bearing reason is that these roots are READ FROM — resolveBuildRoot joins package.json onto packageRoot, collectBuildEntries walks buildRoot, and the lockfile lookup walks packageRoot's ancestors — so stripping here would break analyzer identity on a deep checkout for exactly the reason the ingress strip was withdrawn. Helper: near-miss spellings (`\\??\`, `\\?\\`, single-backslash, GLOBALROOT) and forward-slash/mixed-separator forms are pinned as untouched, plus degenerate and empty input. canonicalizePath: volume-GUID and `\\.\` are asserted unmatched through canonicalizePath itself, not just the helper, so the deliberate branch asymmetry is pinned where it is consumed. assertSafeStoragePath: prefixed path + prefixed storagePath passes, mixed form throws. This guard fronts fs.rm(recursive) and deliberately does NOT canonicalize; "complete the fix by stripping here too" is the tempting follow-up and would widen what the recursive delete accepts. resolveRegisteredRepoEntry: the consumer surface the fix exists for — an MCP `repo` argument or `?repo=` value in the prefixed spelling now resolves its un-prefixed entry, and a prefixed path naming no entry still fails closed. Verified to discriminate: reverting the strip fails this test along with the three catch-branch ones. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119fkrRFdQDQKh58LY9Tqh2 --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
150 lines
7.3 KiB
TypeScript
150 lines
7.3 KiB
TypeScript
/**
|
|
* #2667 — the Windows extended-length (`\\?\`) prefix must never survive into a
|
|
* path GitNexus compares or keys on.
|
|
*
|
|
* `stripWindowsLongPathPrefix` is a POSIX no-op, so these assertions only bite on
|
|
* windows-latest; the file is registered in `scripts/cross-platform-tests.ts` for
|
|
* exactly that reason. Like `analyzer-identity-path-normalization.test.ts`, it holds
|
|
* ONLY pure-function assertions with an explicit `platform` argument — no fixture,
|
|
* no filesystem — so it stays green on every runner.
|
|
*/
|
|
import { describe, it, expect } from 'vitest';
|
|
import path from 'path';
|
|
import { stripWindowsLongPathPrefix } from '../../src/lib/utils.js';
|
|
|
|
describe('stripWindowsLongPathPrefix (#2667)', () => {
|
|
it('strips the prefix from a drive path', () => {
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\D:\\Projects\\repo', 'win32')).toBe(
|
|
'D:\\Projects\\repo',
|
|
);
|
|
});
|
|
|
|
it('rewrites the UNC form back to its `\\\\server\\share` shape', () => {
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\UNC\\server\\share\\repo', 'win32')).toBe(
|
|
'\\\\server\\share\\repo',
|
|
);
|
|
});
|
|
|
|
// The namespace `\\?\` addresses is case-insensitive, so a caller can spell
|
|
// the token in any case. Matching only `UNC` left `\\?\unc\…` prefixed, which
|
|
// is the #2667 registry mismatch all over again on a network share.
|
|
it('rewrites the UNC form whatever case the token is spelled in', () => {
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\unc\\server\\share\\repo', 'win32')).toBe(
|
|
'\\\\server\\share\\repo',
|
|
);
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\Unc\\server\\share\\repo', 'win32')).toBe(
|
|
'\\\\server\\share\\repo',
|
|
);
|
|
});
|
|
|
|
it('leaves a volume-GUID path untouched — its remainder is not a usable path', () => {
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\Volume{1a2b3c4d}\\repo', 'win32')).toBe(
|
|
'\\\\?\\Volume{1a2b3c4d}\\repo',
|
|
);
|
|
});
|
|
|
|
it('leaves the `\\\\.\\` device namespace untouched', () => {
|
|
// Most of what it addresses is not a filesystem path at all.
|
|
expect(stripWindowsLongPathPrefix('\\\\.\\D:\\repo', 'win32')).toBe('\\\\.\\D:\\repo');
|
|
expect(stripWindowsLongPathPrefix('\\\\.\\PhysicalDrive0', 'win32')).toBe(
|
|
'\\\\.\\PhysicalDrive0',
|
|
);
|
|
});
|
|
|
|
// Degenerate extended paths: stripping these would emit something worse than
|
|
// the input. `\\?\UNC` has no share to keep, so a blind slice yields the bare
|
|
// root `\\`; `\\?\D:foo` is drive-RELATIVE, so a blind slice yields `D:foo`,
|
|
// which is not absolute and would resolve against the process cwd. Both are
|
|
// left untouched so they simply fail to match a registry entry.
|
|
it('leaves a UNC prefix with no share component untouched', () => {
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\UNC\\', 'win32')).toBe('\\\\?\\UNC\\');
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\UNC', 'win32')).toBe('\\\\?\\UNC');
|
|
});
|
|
|
|
it('leaves a drive-relative extended path untouched, so output stays absolute', () => {
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\D:foo', 'win32')).toBe('\\\\?\\D:foo');
|
|
expect(path.win32.isAbsolute(stripWindowsLongPathPrefix('\\\\?\\D:\\foo', 'win32'))).toBe(true);
|
|
});
|
|
|
|
it('is a no-op on already-canonical drive and UNC paths', () => {
|
|
expect(stripWindowsLongPathPrefix('D:\\Projects\\repo', 'win32')).toBe('D:\\Projects\\repo');
|
|
expect(stripWindowsLongPathPrefix('\\\\server\\share\\repo', 'win32')).toBe(
|
|
'\\\\server\\share\\repo',
|
|
);
|
|
});
|
|
|
|
it('is idempotent — it runs wherever a comparison key is built', () => {
|
|
const once = stripWindowsLongPathPrefix('\\\\?\\D:\\Projects\\repo', 'win32');
|
|
expect(stripWindowsLongPathPrefix(once, 'win32')).toBe(once);
|
|
|
|
const uncOnce = stripWindowsLongPathPrefix('\\\\?\\UNC\\server\\share\\repo', 'win32');
|
|
expect(stripWindowsLongPathPrefix(uncOnce, 'win32')).toBe(uncOnce);
|
|
});
|
|
|
|
// Near-miss spellings must fail closed rather than be half-normalized: none of
|
|
// these is the extended-length prefix, so none may be sliced.
|
|
it('leaves near-miss namespace spellings untouched', () => {
|
|
expect(stripWindowsLongPathPrefix('\\\\??\\D:\\repo', 'win32')).toBe('\\\\??\\D:\\repo');
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\\\D:\\repo', 'win32')).toBe('\\\\?\\\\D:\\repo');
|
|
expect(stripWindowsLongPathPrefix('\\?\\D:\\repo', 'win32')).toBe('\\?\\D:\\repo');
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\GLOBALROOT\\Device\\X', 'win32')).toBe(
|
|
'\\\\?\\GLOBALROOT\\Device\\X',
|
|
);
|
|
});
|
|
|
|
it('handles degenerate and empty input without throwing', () => {
|
|
expect(stripWindowsLongPathPrefix('', 'win32')).toBe('');
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\', 'win32')).toBe('\\\\?\\');
|
|
expect(stripWindowsLongPathPrefix('\\\\', 'win32')).toBe('\\\\');
|
|
expect(stripWindowsLongPathPrefix('D:', 'win32')).toBe('D:');
|
|
});
|
|
|
|
// The helper matches the backslash spelling only, by design — `path.resolve`
|
|
// folds `//?/` into it first. A half-converted path is left alone rather than
|
|
// sliced on one separator convention and rejoined on the other.
|
|
it('leaves a forward-slash or mixed-separator prefix untouched', () => {
|
|
expect(stripWindowsLongPathPrefix('//?/D:/repo', 'win32')).toBe('//?/D:/repo');
|
|
expect(stripWindowsLongPathPrefix('//?/UNC/server/share', 'win32')).toBe(
|
|
'//?/UNC/server/share',
|
|
);
|
|
// Backslash prefix with a forward-slash body IS sliced — the prefix matched.
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\D:\\a/b/c', 'win32')).toBe('D:\\a/b/c');
|
|
});
|
|
|
|
it('is a no-op off Windows, where `\\\\?\\…` is an ordinary filename', () => {
|
|
expect(stripWindowsLongPathPrefix('\\\\?\\D:\\repo', 'linux')).toBe('\\\\?\\D:\\repo');
|
|
expect(stripWindowsLongPathPrefix('/home/node/repo', 'linux')).toBe('/home/node/repo');
|
|
});
|
|
|
|
// The leak this normalization exists to prevent. `path.win32.relative` cannot
|
|
// express a relative path between a prefixed and an un-prefixed form of the SAME
|
|
// directory — they share no root — so it returns the absolute target instead.
|
|
// That absolute string is exactly what #2667 reported inside node IDs
|
|
// (`Function:\\?\D:\…\market.move:…`), and it is the same defect class as the
|
|
// cross-drive `isInside` bug fixed in #2688.
|
|
it('makes a mixed-prefix relativization relative again', () => {
|
|
const prefixed = '\\\\?\\D:\\repo';
|
|
const child = 'D:\\repo\\a\\b.move';
|
|
|
|
expect(path.win32.relative(prefixed, child)).toBe(child);
|
|
expect(path.win32.relative(stripWindowsLongPathPrefix(prefixed, 'win32'), child)).toBe(
|
|
'a\\b.move',
|
|
);
|
|
});
|
|
|
|
// Why `canonicalizePath`'s `catch` branch leaked and its realpath branch did
|
|
// not. The repo-manager regression tests for that branch can only run on
|
|
// windows-latest, so pin the underlying platform fact here, where it runs
|
|
// everywhere: `path.resolve` carries the prefix through untouched, which is
|
|
// all the fallback branch used to do. Also pins the forward-slash spelling
|
|
// that the helper deliberately does not match, because `resolve` folds it
|
|
// into the backslash form first.
|
|
it('pins that path.resolve preserves the prefix (the fallback branch #2667 leaked through)', () => {
|
|
expect(path.win32.resolve('\\\\?\\D:\\repo\\sub')).toBe('\\\\?\\D:\\repo\\sub');
|
|
expect(path.win32.resolve('//?/D:/repo/sub')).toBe('\\\\?\\D:\\repo\\sub');
|
|
|
|
expect(stripWindowsLongPathPrefix(path.win32.resolve('\\\\?\\D:\\repo\\sub'), 'win32')).toBe(
|
|
'D:\\repo\\sub',
|
|
);
|
|
});
|
|
});
|