2.41.0 export-kicad reports successful writes but creates no output files

by adom

adom-lbr — the EDA library translator. Bring a component in from any supported EDA tool and convert it to any other (KiCad ⇄ Altium ⇄ EAGLE/Fusion) through one canonical adom-lbr JSON — symbol + footprint + 3D + pin↔pad map. Altium is written natively (no Altium needed). Includes the adom-lbr Manager: browse wiki components and view symbol/footprint/3D + the per-EDA layer stackup.

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 1mo ago ·closed by Colby Knox

Environment: Ubuntu 24.04.4, WSL2; installed adom-lbr 2.41.0. A retained project build reports 2.38.0 and provides the comparison. No desktop bridge is involved.

export-kicad returns exit 0 and prints OK: wrote ... for both output files, but the destination directory does not exist afterwards. The same canonical input and fresh absolute output path work with the retained project build. The failure reproduced with relative and absolute output paths. The installed binary was not replaced.

Reproduce with the attached two-pin capacitor canonical JSON:

adom-lbr export-kicad 0402B104J160CT.adom-lbr.json --out-dir /tmp/lbr-export-repro

Expected: both .kicad_sym and .kicad_mod exist, are readable, and correspond to the input.

Observed: success text and exit 0, no directory or files. See the attached exact output, version, binary SHA-256 and filesystem observations. The input contains no 3D model, so this is not a missing model asset.

Please make successful export contingent on completed writes and read-back, return nonzero on output failure, and include AI hints with output paths, bytes, hashes and validation status. A dry-run, if intentional, must explicitly say no files were written rather than OK: wrote.

result.json

0402B104J160CT.adom-lbr.json

1 Reply

Colby Knox · 1mo ago

Fixed in 2.41.1 (published; wiki cfeaf33b, GitHub 78e0ec1), closing against the release.

Root cause, confirmed by reproduction with your attached 0402B104J160CT JSON and a nonexistent --out-dir: every output path in the tool went through fs::write(..).ok(), which swallows the error, and no verb created its output directory. So a missing directory failed both writes silently and the success line printed anyway. Not a dry run; a swallowed error. The retained 2.38.0 build only "worked" because its output directory already existed.

What ships: one verified-write helper behind every "OK: wrote" site (export-kicad, export-altium, export-intlib, add-to-schlib, both import verbs, the skill install). It creates the directory, writes, reads the file back, requires the bytes to match, and prints a per-file receipt; any failure is ERROR: [OUTPUT_NOT_WRITTEN] <path>: <cause> with exit 2. Your exact command shape now produces:

OK: wrote .../0402B104J160CT.kicad_sym (2 pins) + .../0402B104J160CT.kicad_mod (2 pads, 4 graphics)
Hint: verified .../0402B104J160CT.kicad_sym (1806 bytes, sha256 1c26e0d9dca1f118..., read back identical)
Hint: verified .../0402B104J160CT.kicad_mod (781 bytes, sha256 278f5a72c9777b65..., read back identical)

and an independent sha256sum of the files on disk matches those digests byte-for-byte. An unwritable target (--out-dir /proc/x) now answers ERROR: [OUTPUT_NOT_WRITTEN] cannot create /proc/x: No such file or directory with exit 2. Pinned in the suite (24 tests): the helper creates a nested missing directory and returns the sha256 of the bytes it read back.

The "OK: wrote" line keeps its exact shape so anything parsing it (the wiki export worker) is unaffected; the receipts are additional Hint lines, which is the CLI's existing contract for machine-readable extras.