morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4707] [Bug] Windows: rea analyze rejects backslash absolute paths with "Ambiguous Windows path component is unsupported" (Win32 50) #2455

New issue

Closed

opened 2026-10-17 21:04:56 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-17 21:04:56 +00:00

Owner

Originally created by @kentyao35 on GitHub (Oct 17, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4707

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

On this Windows host, rea doctor is fully green for every Ghidra check — including ghidra-native_authority, ghidra-native_decompiler, ghidra-java, ghidra-headless — and the Ghidra provider is configured=true available=true providerVersion=12.1.4.

Nevertheless rea analyze <target> fails before analysis whenever the target path is passed with Windows backslash separators. Passing the identical file with forward-slash separators succeeds and produces a full Ghidra-derived Evidence record.

The failure is raised by the bundled Windows native addon at target-snapshot admission, not by Ghidra:

{
  "error": "Analysis failed",
  "code": "execution_failure",
  "category": "execution_failure",
  "retryable": false,
  "details": {
    "provider_id": "ghidra",
    "operation": "list_documents",
    "diagnostics": {
      "target_path": "C://Users//<user>//tools//ghidra//repro//h3.exe",
      "target_sha256": "a90c3fb350a11c6f6a6efa9607987d924d1de65e09ca9faf2e0e0e00531ee335",
      "transport": "authenticated-loopback-tcp",
      "provider_version": "12.1.4",
      "failure_cause": {
        "name": "Error",
        "message": "Ambiguous Windows path component is unsupported [C:\\\\Users\\\\<user>\\\\tools\\\\ghidra\\\\repro\\\\h3.exe] (Win32 50): 不支持该请求。\r\n",
        "code": "ERR_REA_WINDOWS_NATIVE"
      },
      "failure_kind": "start",
      "failure_message": "Ghidra target snapshot failed admission"
    }
  }
}

Two things are worth flagging in that payload:

target_path is reported as C://Users//<user>//... — every backslash appears to have become a doubled forward slash. Split on /, that string yields empty path components, which plausibly is what the native component walker classifies as "ambiguous". A single-slash-normalized path (C:/Users/<user>/...) is accepted by the same walker in the same build.
The user-visible remediation says "Run rea doctor and review the reported details", but rea doctor reports healthy for every Ghidra scope on this host. The diagnostic points the operator at a component that is demonstrably fine, which cost me a long time before I noticed the separator variable.

Reproduction

Deterministic, reproduced 5/5 times across two filenames and one repeated run. Same byte-identical file (sha256 a90c3fb3…), same directory, same minute; only the separator in the argument differs.

# 0. Setup used (read-only; nothing else configured)
#    rea-agents 6.5.0 from npm, Ghidra 12.1.4 PUBLIC, Temurin JDK 21.0.12.1+1
$env:JAVA_HOME        = "C:\Users\<user>\tools\jdk\jdk-21.0.12.1+1"
$env:GHIDRA_INSTALL_DIR = "C:\Users\<user>\tools\ghidra\ghidra_12.1.4_PUBLIC"

# 1. Any PE target; a stock Windows binary is enough
Copy-Item C:\Windows\System32\hostname.exe C:\Users\<user>\repro\h1.exe
Copy-Item C:\Windows\System32\hostname.exe C:\Users\<user>\repro\h2.exe

# 2. Backslash absolute path  -> FAILS  (3/3)
npx -y rea-agents@6.5.0 analyze "C:\Users\<user>\repro\h1.exe" --format json
# {"error":"Analysis failed","code":"execution_failure", ... "Ghidra target snapshot failed admission"}

# 3. Forward-slash absolute path, same file -> SUCCEEDS  (2/2)
npx -y rea-agents@6.5.0 analyze "C:/Users/<user>/repro/h1.exe" --format json
# {"evidence_id":"ev_d7e207…","subject":{"name":"h1.exe","digest":{"sha256":"a90c3fb3…"},"format":"pe","architecture":"x86_64"}, ...}

# 4. Cross-check on the second copy — the pattern follows the separator, not the file
npx -y rea-agents@6.5.0 analyze "C:\Users\<user>\repro\h2.exe" --format json   # FAILS
npx -y rea-agents@6.5.0 analyze "C:/Users/<user>/repro/h2.exe" --format json   # SUCCEEDS

Result matrix (identical sha256 a90c3fb350a11c6f6a6efa9607987d924d1de65e09ca9faf2e0e0e00531ee335 for every row):

Argument form	h1.exe	h2.exe	h3.exe
`C:\Users\…\hN.exe` (backslash)	fail (Win32 50)	fail (Win32 50)	fail (Win32 50)
`C:/Users/…/hN.exe` (forward slash)	success	success	not run

Additional observations from the same session:

A bare filename (analyze whoami.exe with the file in the CWD) succeeds — the resolved path is handed to the provider with forward slashes.
The failure is independent of drive and path shape: it also reproduced with C:\rea\a.exe (short, no hyphens, outside the user profile) and on a second NTFS volume (E:\rea-test\whoami.exe).
The failure is fast and non-retryable (failure_kind: start), i.e. the provider process is never asked to analyze anything.

Expected behavior

analyze should accept the target path with either separator on Windows. C:\Users\<user>\repro\h1.exe and C:/Users/<user>/repro/h1.exe name the same object; the CLI already resolves relative inputs to an absolute path, so separator normalization should happen at the same boundary before the path is submitted to native admission.

Concretely, one of:

Normalize \ → / once (not twice) when building the path handed to the native snapshot layer, at the point where GhidraProviderClient currently passes the raw user input (targetPath: installation.platform === "win32" ? (target.sourcePath ?? target.path) : target.path). The non-win32 branch already uses the normalized target.path; the win32 branch reaches for the raw sourcePath.
Or make the native component walker split on both / and \ and reject only genuinely ambiguous forms (e.g. \\?\ prefixes it does not support), instead of classifying an ordinary drive-qualified path as ambiguous.

Secondary, lower priority: when the failure cause is ERR_REA_WINDOWS_NATIVE at admission, the remediation should not be "run rea doctor" unconditionally — on a host where every provider scope is healthy that advice is actively misleading. Echoing the rejected path component (or "path separator normalization failed") would have made this self-diagnosing.

Impact and scope

Functional: on this host, native analysis (PE / Ghidra) is entirely unusable through the documented absolute-path invocation, while the capability itself is healthy. Any consumer that formats paths with path.win32.join / path.resolve (the Windows default!) hands REA backslashes, so the practical blast radius is "every Windows caller that passes an absolute path", including MCP tool calls generated from a Windows-cwd path.
Frequency: deterministic, 5/5 in this session, both arms of the matrix.
Not affected: analyze-javascript-application against a directory (returns full Evidence), bare-filename invocation, and forward-slash absolute paths — the workaround is reliable and unblocks real work immediately.
Evidence integrity: not implicated. When admission passes, the evidence record is well-formed and Ghidra-derived (document: target-a90c3fb350a1.exe, image_base: 0x140000000, segment_count: 8, procedure_count: 83, string_count: 100, authority: shipped-artifact, confidence: derived).
Distinct from #1701: that issue is the native-authority self-test gate (Delete owned object by handle failed, Win32 5 / Win32 32) which hard-gates the provider off. On this host, with 6.5.0, ghidra-native_authority reports ok: true / healthy, the provider loads, and the failure happens later, at target-snapshot admission (Win32 50). Related family, different stage: #1701, #2257 (Open Windows path component failed … Win32 32), #2181 (Win32 87).
Untested and left unknown: whether UNC paths (\\server\share\x.exe), long-path \\?\C:\… prefixes, or non-ASCII path components hit the same admission branch; and whether the MCP surface shows a different error shape for the same input. I did not test those.

REA version

rea-agents 6.5.0   (npm, published 2026-10-14T13:10:41Z)
bundled native/windows/build/rea-windows-x64.node  —  873,593 bytes, sha256 665c57ab90aef0712a6aafc423c7992a…

Runtime and platform

Node    v22.22.2 (also present: v22.22.1)
OS      Windows 10 Pro 22H2, build 10.0.19045.6466, x64
Volumes C: and E:, both NTFS, healthy, fixed
Ghidra  12.1.4 PUBLIC (Ghidra_12.1.4_PUBLIC_20260921)
JDK     Eclipse Temurin 21.0.12.1+1 (64-bit full JDK; Ghidra's application.java.min=21)
REA env JAVA_HOME + GHIDRA_INSTALL_DIR only

rea doctor --json on this host: scope_checks all ok:true for node, host, ghidra, ghidra-platform, ghidra-architecture, ghidra-installation, ghidra-version, ghidra-headless, ghidra-native_decompiler, ghidra-java, ghidra-native_authority. The overall healthy:false comes only from unconfigured other engines (hopper, ida-registration, jadx) and absent registrations for other clients — unrelated to this report.

Target and artifact context

PE32+ x86_64 console executable (hostname.exe copied from System32), 73,728 bytes, sha256 a90c3fb350a11c6f6a6efa9607987d924d1de65e09ca9faf2e0e0e00531ee335. No packing, no signatures involved, single file, local disk. Nothing about the artifact is unusual — it is the separator that decides the outcome.

Interface

CLI

Failure stage

Setup or provider admission

Relevant output or evidence

Failure (backslash), trimmed to the diagnostic fields that matter — obtained by npx -y rea-agents@6.5.0 analyze "C:\Users\<user>\repro\h3.exe" --format json:

provider_id:    ghidra
operation:      list_documents
target_path:    C://Users//<user>//tools//ghidra//repro//h3.exe     <-- doubled separators
failure_kind:   start
failure_message: Ghidra target snapshot failed admission
failure_cause:  Ambiguous Windows path component is unsupported
                [C:\Users\<user>\tools\ghidra\repro\h3.exe] (Win32 50)
                code=ERR_REA_WINDOWS_NATIVE
provider_version: 12.1.4
transport:      authenticated-loopback-tcp

Success (forward slash), same file, --format json, trimmed:

{
  "evidence_id": "ev_d7e207290bfffaf3db5ac7f9cbf87dedfcb2282f9426bff6de2155f948829663",
  "subject": {
    "name": "h2.exe",
    "digest": { "sha256": "a90c3fb350a11c6f6a6efa9607987d924d1de65e09ca9faf2e0e0e00531ee335" },
    "local_path": "C:\\Users\\<user>\\tools\\ghidra\\repro\\h2.exe",
    "format": "pe",
    "architecture": "x86_64"
  },
  "provider": { "id": "rea-workflow", "version": "1" },
  "operation": "binary_overview",
  "normalized_result": {
    "document": "target-a90c3fb350a1.exe",
    "image_base": "0x140000000",
    "segment_count": 8,
    "procedure_count": 83,
    "string_count": 100
  },
  "confidence": "derived",
  "authority": "shipped-artifact"
}

Note that subject.local_path in the successful record is rendered with backslashes again (C:\Users\…), i.e. the artifact is registered correctly — only the string handed to native admission differs.

Source-derived observation (not execution)

Bundled dist/ghidra/GhidraProviderClient.js (6.5.0, around line 354) selects the path that becomes the provider's targetPath:

targetPath: installation.platform === "win32"
    ? (target.sourcePath ?? target.path)
    : target.path,

On non-win32 the normalized target.path is used, which is already separator-normalized; on win32 the raw target.sourcePath is preferred. That is consistent with the observed asymmetry, but I have not traced where the \ → // doubling occurs (the message and path both originate from the native addon, native/windows/build/rea-windows-x64.node), so treat the mechanism as a hypothesis and the behavior above as the observed fact.

Workaround

Pass forward-slash paths on Windows; equivalent to path.replaceAll('\\', '/') before invoking analyze (and before generating any MCP analyze call from a Windows CWD). Verified to yield complete Ghidra evidence on this host, including the 2×2 matrix above.

Originally created by @kentyao35 on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4707 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior On this Windows host, `rea doctor` is fully green for every Ghidra check — including `ghidra-native_authority`, `ghidra-native_decompiler`, `ghidra-java`, `ghidra-headless` — and the Ghidra provider is `configured=true available=true providerVersion=12.1.4`. Nevertheless `rea analyze <target>` fails before analysis whenever the target path is passed with **Windows backslash separators**. Passing the **identical file** with forward-slash separators succeeds and produces a full Ghidra-derived Evidence record. The failure is raised by the bundled Windows native addon at target-snapshot admission, not by Ghidra: ```json { "error": "Analysis failed", "code": "execution_failure", "category": "execution_failure", "retryable": false, "details": { "provider_id": "ghidra", "operation": "list_documents", "diagnostics": { "target_path": "C://Users//<user>//tools//ghidra//repro//h3.exe", "target_sha256": "a90c3fb350a11c6f6a6efa9607987d924d1de65e09ca9faf2e0e0e00531ee335", "transport": "authenticated-loopback-tcp", "provider_version": "12.1.4", "failure_cause": { "name": "Error", "message": "Ambiguous Windows path component is unsupported [C:\\\\Users\\\\<user>\\\\tools\\\\ghidra\\\\repro\\\\h3.exe] (Win32 50): 不支持该请求。\r\n", "code": "ERR_REA_WINDOWS_NATIVE" }, "failure_kind": "start", "failure_message": "Ghidra target snapshot failed admission" } } } ``` Two things are worth flagging in that payload: 1. `target_path` is reported as `C://Users//<user>//...` — every backslash appears to have become a **doubled** forward slash. Split on `/`, that string yields empty path components, which plausibly is what the native component walker classifies as "ambiguous". A single-slash-normalized path (`C:/Users/<user>/...`) is accepted by the same walker in the same build. 2. The user-visible remediation says *"Run `rea doctor` and review the reported details"*, but `rea doctor` reports `healthy` for every Ghidra scope on this host. The diagnostic points the operator at a component that is demonstrably fine, which cost me a long time before I noticed the separator variable. ### Reproduction Deterministic, reproduced 5/5 times across two filenames and one repeated run. Same byte-identical file (`sha256 a90c3fb3…`), same directory, same minute; **only the separator in the argument differs**. ```powershell # 0. Setup used (read-only; nothing else configured) # rea-agents 6.5.0 from npm, Ghidra 12.1.4 PUBLIC, Temurin JDK 21.0.12.1+1 $env:JAVA_HOME = "C:\Users\<user>\tools\jdk\jdk-21.0.12.1+1" $env:GHIDRA_INSTALL_DIR = "C:\Users\<user>\tools\ghidra\ghidra_12.1.4_PUBLIC" # 1. Any PE target; a stock Windows binary is enough Copy-Item C:\Windows\System32\hostname.exe C:\Users\<user>\repro\h1.exe Copy-Item C:\Windows\System32\hostname.exe C:\Users\<user>\repro\h2.exe # 2. Backslash absolute path -> FAILS (3/3) npx -y rea-agents@6.5.0 analyze "C:\Users\<user>\repro\h1.exe" --format json # {"error":"Analysis failed","code":"execution_failure", ... "Ghidra target snapshot failed admission"} # 3. Forward-slash absolute path, same file -> SUCCEEDS (2/2) npx -y rea-agents@6.5.0 analyze "C:/Users/<user>/repro/h1.exe" --format json # {"evidence_id":"ev_d7e207…","subject":{"name":"h1.exe","digest":{"sha256":"a90c3fb3…"},"format":"pe","architecture":"x86_64"}, ...} # 4. Cross-check on the second copy — the pattern follows the separator, not the file npx -y rea-agents@6.5.0 analyze "C:\Users\<user>\repro\h2.exe" --format json # FAILS npx -y rea-agents@6.5.0 analyze "C:/Users/<user>/repro/h2.exe" --format json # SUCCEEDS ``` Result matrix (identical `sha256 a90c3fb350a11c6f6a6efa9607987d924d1de65e09ca9faf2e0e0e00531ee335` for every row): | Argument form | h1.exe | h2.exe | h3.exe | |---|---|---|---| | `C:\Users\…\hN.exe` (backslash) | fail (Win32 50) | fail (Win32 50) | fail (Win32 50) | | `C:/Users/…/hN.exe` (forward slash) | **success** | **success** | not run | Additional observations from the same session: - A **bare filename** (`analyze whoami.exe` with the file in the CWD) succeeds — the resolved path is handed to the provider with forward slashes. - The failure is **independent of drive and path shape**: it also reproduced with `C:\rea\a.exe` (short, no hyphens, outside the user profile) and on a second NTFS volume (`E:\rea-test\whoami.exe`). - The failure is **fast and non-retryable** (`failure_kind: start`), i.e. the provider process is never asked to analyze anything. ### Expected behavior `analyze` should accept the target path with either separator on Windows. `C:\Users\<user>\repro\h1.exe` and `C:/Users/<user>/repro/h1.exe` name the same object; the CLI already resolves relative inputs to an absolute path, so separator normalization should happen at the same boundary before the path is submitted to native admission. Concretely, one of: 1. Normalize `\` → `/` **once** (not twice) when building the path handed to the native snapshot layer, at the point where `GhidraProviderClient` currently passes the raw user input (`targetPath: installation.platform === "win32" ? (target.sourcePath ?? target.path) : target.path`). The non-win32 branch already uses the normalized `target.path`; the win32 branch reaches for the raw `sourcePath`. 2. Or make the native component walker split on both `/` and `\` and reject only genuinely ambiguous forms (e.g. `\\?\` prefixes it does not support), instead of classifying an ordinary drive-qualified path as ambiguous. Secondary, lower priority: when the failure cause is `ERR_REA_WINDOWS_NATIVE` at admission, the remediation should not be "run `rea doctor`" unconditionally — on a host where every provider scope is healthy that advice is actively misleading. Echoing the rejected path component (or "path separator normalization failed") would have made this self-diagnosing. ### Impact and scope - **Functional**: on this host, native analysis (PE / Ghidra) is entirely unusable through the documented absolute-path invocation, while the capability itself is healthy. Any consumer that formats paths with `path.win32.join` / `path.resolve` (the Windows default!) hands REA backslashes, so the practical blast radius is "every Windows caller that passes an absolute path", including MCP tool calls generated from a Windows-cwd path. - **Frequency**: deterministic, 5/5 in this session, both arms of the matrix. - **Not affected**: `analyze-javascript-application` against a directory (returns full Evidence), bare-filename invocation, and forward-slash absolute paths — the workaround is reliable and unblocks real work immediately. - **Evidence integrity**: not implicated. When admission passes, the evidence record is well-formed and Ghidra-derived (`document: target-a90c3fb350a1.exe`, `image_base: 0x140000000`, `segment_count: 8`, `procedure_count: 83`, `string_count: 100`, `authority: shipped-artifact`, `confidence: derived`). - **Distinct from #1701**: that issue is the native-authority *self-test* gate (`Delete owned object by handle failed`, Win32 5 / Win32 32) which hard-gates the provider off. On this host, with 6.5.0, `ghidra-native_authority` reports `ok: true / healthy`, the provider loads, and the failure happens later, at target-snapshot admission (Win32 50). Related family, different stage: #1701, #2257 (`Open Windows path component failed … Win32 32`), #2181 (Win32 87). - Untested and left unknown: whether UNC paths (`\\server\share\x.exe`), long-path `\\?\C:\…` prefixes, or non-ASCII path components hit the same admission branch; and whether the MCP surface shows a different error shape for the same input. I did not test those. ### REA version ``` rea-agents 6.5.0 (npm, published 2026-10-14T13:10:41Z) bundled native/windows/build/rea-windows-x64.node — 873,593 bytes, sha256 665c57ab90aef0712a6aafc423c7992a… ``` ### Runtime and platform ``` Node v22.22.2 (also present: v22.22.1) OS Windows 10 Pro 22H2, build 10.0.19045.6466, x64 Volumes C: and E:, both NTFS, healthy, fixed Ghidra 12.1.4 PUBLIC (Ghidra_12.1.4_PUBLIC_20260921) JDK Eclipse Temurin 21.0.12.1+1 (64-bit full JDK; Ghidra's application.java.min=21) REA env JAVA_HOME + GHIDRA_INSTALL_DIR only ``` `rea doctor --json` on this host: `scope_checks` all `ok:true` for `node`, `host`, `ghidra`, `ghidra-platform`, `ghidra-architecture`, `ghidra-installation`, `ghidra-version`, `ghidra-headless`, `ghidra-native_decompiler`, `ghidra-java`, `ghidra-native_authority`. The overall `healthy:false` comes only from unconfigured *other* engines (`hopper`, `ida-registration`, `jadx`) and absent registrations for other clients — unrelated to this report. ### Target and artifact context PE32+ x86_64 console executable (`hostname.exe` copied from `System32`), 73,728 bytes, `sha256 a90c3fb350a11c6f6a6efa9607987d924d1de65e09ca9faf2e0e0e00531ee335`. No packing, no signatures involved, single file, local disk. Nothing about the artifact is unusual — it is the separator that decides the outcome. ### Interface CLI ### Failure stage Setup or provider admission ### Relevant output or evidence Failure (backslash), trimmed to the diagnostic fields that matter — obtained by `npx -y rea-agents@6.5.0 analyze "C:\Users\<user>\repro\h3.exe" --format json`: ``` provider_id: ghidra operation: list_documents target_path: C://Users//<user>//tools//ghidra//repro//h3.exe <-- doubled separators failure_kind: start failure_message: Ghidra target snapshot failed admission failure_cause: Ambiguous Windows path component is unsupported [C:\Users\<user>\tools\ghidra\repro\h3.exe] (Win32 50) code=ERR_REA_WINDOWS_NATIVE provider_version: 12.1.4 transport: authenticated-loopback-tcp ``` Success (forward slash), same file, `--format json`, trimmed: ```json { "evidence_id": "ev_d7e207290bfffaf3db5ac7f9cbf87dedfcb2282f9426bff6de2155f948829663", "subject": { "name": "h2.exe", "digest": { "sha256": "a90c3fb350a11c6f6a6efa9607987d924d1de65e09ca9faf2e0e0e00531ee335" }, "local_path": "C:\\Users\\<user>\\tools\\ghidra\\repro\\h2.exe", "format": "pe", "architecture": "x86_64" }, "provider": { "id": "rea-workflow", "version": "1" }, "operation": "binary_overview", "normalized_result": { "document": "target-a90c3fb350a1.exe", "image_base": "0x140000000", "segment_count": 8, "procedure_count": 83, "string_count": 100 }, "confidence": "derived", "authority": "shipped-artifact" } ``` Note that `subject.local_path` in the successful record is rendered with backslashes again (`C:\Users\…`), i.e. the artifact is registered correctly — only the string handed to native admission differs. ### Source-derived observation (not execution) Bundled `dist/ghidra/GhidraProviderClient.js` (6.5.0, around line 354) selects the path that becomes the provider's `targetPath`: ```js targetPath: installation.platform === "win32" ? (target.sourcePath ?? target.path) : target.path, ``` On non-win32 the normalized `target.path` is used, which is already separator-normalized; on win32 the raw `target.sourcePath` is preferred. That is consistent with the observed asymmetry, but I have **not** traced where the `\` → `//` doubling occurs (the message and path both originate from the native addon, `native/windows/build/rea-windows-x64.node`), so treat the mechanism as a hypothesis and the behavior above as the observed fact. ### Workaround Pass forward-slash paths on Windows; equivalent to `path.replaceAll('\\', '/')` before invoking `analyze` (and before generating any MCP `analyze` call from a Windows CWD). Verified to yield complete Ghidra evidence on this host, including the 2×2 matrix above.

bsakaguchi closed this issue

2026-10-17 21:04:56 +00:00

bsakaguchi commented

2026-10-17 21:04:59 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 17, 2026):

Reproduced the same class of issue — on Windows, passing an absolute path with backslash separators (C:\Users\...) trips the native addon's 'Ambiguous Windows path component' rejection at target-snapshot admission, while the forward-slash form succeeds. Two suggestions for the fix: normalize drive-letter absolute paths to forward slashes at the admission boundary (and cover UNC \\server\share paths, which hit the same ambiguity), and include the original user-supplied string in the error diagnostic — the report shows a normalized C://Users//... form, so it is hard to tell whether the failure is caused by user input or by the normalization step itself. A small regression that runs analyze with backslash, forward-slash, and UNC variants of the same target would lock the behavior down.

@XinwangTao commented on GitHub (Oct 17, 2026): Reproduced the same class of issue — on Windows, passing an absolute path with backslash separators (`C:\Users\...`) trips the native addon's 'Ambiguous Windows path component' rejection at target-snapshot admission, while the forward-slash form succeeds. Two suggestions for the fix: normalize drive-letter absolute paths to forward slashes at the admission boundary (and cover UNC `\\server\share` paths, which hit the same ambiguity), and include the original user-supplied string in the error diagnostic — the report shows a normalized `C://Users//...` form, so it is hard to tell whether the failure is caused by user input or by the normalization step itself. A small regression that runs `analyze` with backslash, forward-slash, and UNC variants of the same target would lock the behavior down.

bsakaguchi referenced this issue

2026-10-31 01:05:03 +00:00

[PR #2455] [MERGED] perf(flutter): add opt-in retained AOT summary and string pages #5240

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#2455

No description provided.

Rows
Columns