Windows: VFS spawn interception is POSIX-only — packaged apps cannot spawn VFS-resident tools (java, sibling payload binaries)

[ronaldtse]

Summary

process_c_tebako_spawn.patch (patches/3.3) is POSIX-only: the entire tfs_spawn_prepare implementation sits under #ifndef _WIN32; the win32 build gets #define tfs_spawn_prepare(eargp) ((void)0). Any packaged application that spawns a VFS-resident tool (a sibling payload's binary, e.g. the openjdk slice's java) fails on Windows with a host-side "not recognized" error, because the spawn PATH-searches the host and the VFS mounts are invisible to CreateProcess.

Evidence

• packed-mn v2 assembly PR (Tebako v2 assembly — single fetch→assemble→validate→publish pipeline metanorma/packed-metanorma#251), windows press leg: package boots and compiles (XSLT/HTML pass), then fails exactly at jing's RELAX-NG validation — the first spawn("java", ...):

  Jing failed: '"java"' is not recognized as an internal or external command
  

  Run: https://github.com/metanorma/packed-mn/actions/runs/33048863285/job/98439204317

• The same compile passes on the macOS and Linux legs of the same run (the POSIX hook materializes the exec target and re-enters the namespace via TEBAKO_PRELOAD_SHIM + TEBAKO_TFS_MOUNTS).

• The patch header itself documents the boundary: "Shell-form spawns and bare command names (PATH search) do not resolve through the VFS" — and on Windows no spawn resolves through the VFS.

Why a payload re-pin does not fix it

The openjdk slice's content is correct (its own entrypoint dogfood works: the driver execs the runtime with the image mounted). The gap is the child-spawn mechanism: Windows has no LD_PRELOAD equivalent, libtfs-preload is POSIX-only, and even a single-file materialized java.exe needs its full JRE home tree beside it.

Candidate directions (design decision pending in the ecosystem tracker)

1. Port the spawn interception to the win32 path: whole-tree materialization of the declared tool home into the content-addressed exec cache + child PATH/env amendment. Host spawns keep passing through untouched.
2. Spec-23 composition-level PATH bind: the payload manifest declares path_bins; the driver materializes and binds at startup, so the un-patched win32 spawn finds the tool on a host path. No ruby patch change; the need is declared by the payload and resolved by the composition layer.

Cross-link: packed-mn#251 windows leg is blocked on this decision.