punkshell

1240 Commits

1 Branch

1 Tag

193 MiB

Commit Graph

Author	SHA1	Message	Date
Julian Noble	df83b21a24	bootsupport: replace mounted modpods by delete-then-place, and explain the windows catch-all (punkshell 0.27.4) 'make.tcl bootsupport' failed three times this session replacing the zip-based punk::mix::templates modpod, always with: error copying "<src>" to "<dst>": invalid argument Root cause, demonstrated rather than inferred. A zipfs mount MEMORY-MAPS its archive (tclZipfs.c CreateFileMappingW + MapViewOfFile), and windows refuses to overwrite a file with a user-mapped section open - ERROR_USER_MAPPED_FILE (1224). Any holder blocks it: a running punk shell that loaded the modpod, a src-mode session, or the build itself. Reproduced directly: the same file copies fine unmounted, fails while zipfs-mounted, and copies fine again once unmounted. The message is a dead end BY CONSTRUCTION, which is why two earlier attempts at characterising this (in commit messages and in the archived G-124 detail file - first "a modpod make.tcl has itself mounted", then "a transient lock") were both wrong in different ways. Tcl_WinConvertError maps only Win32 codes 0..267 and sends everything above them to errorTable[1], which is EINVAL - so EVERY high-numbered windows error surfaces as "invalid argument", naming neither cause nor remedy. Byte-identical code in 8.6 and 9.1b1. FIX. ::punkboot::replace_possibly_mapped_file tries the ordinary copy and, on failure, falls back to DELETE-THEN-PLACE, which windows does permit: unlinking a mapped file leaves the holder reading its own mapping while new content lands at the name (measured: delete succeeds while mounted, the mount keeps serving its old content afterwards). Replacement content is staged to a sibling <target>.punkboot-new first, so a mid-sequence failure can never leave the target missing; a 'broken' return - unlinked and unrestorable - is reported as a build failure naming the file to restore by hand. This replaces a narrower prior workaround that only recognised the already-identical case and otherwise recorded FAILED. DIAGNOSIS. ::punkboot::mapped_file_hint fires when a genuine failure carries the catch-all message and explains what it actually means and which process class to look for, instead of leaving "invalid argument" bare. It stays silent for unrelated errors. Verified on the real failure: the bootsupport run that has failed all session now reports "(in-place overwrite refused - replaced by delete-then-place; target was memory-mapped, e.g a mounted modpod)" and completes, with no hand-copy and no rerun. Helper-level checks cover the unmapped path (plain copy, unchanged), the mapped path (recovers, content correct, holder's mapping intact, no temp left behind) and both hint branches. Full suite 1167 tests, 1146 passed, 1 failure - core/tcl exec-14.3, the documented baseline. Documented in src/bootsupport/AGENTS.md, including the general warning that 'invalid argument' from ANY windows file operation in Tcl means "some windows error above 267" and must never be read at face value. Also drafts G-132 (user-approved): the errno catch-all is upstream's defect, not ours, and deserves reporting. The goal is deliberately shaped so an AGENT DRAFTS AND THE DEVELOPER SUBMITS - no account use, no web form, no API - following the G-039 precedent, with the submission-ready text staged in TEMP_REFERENCE and the finding, reproducer, eventual ticket URL and disposition kept in the tracked detail file, because TEMP_REFERENCE is one 'git clean -xdf' from gone. The report's claim is deliberately narrow: the errno conversion is plainly wrong, while the related fact that 'file copy -force' over a mapped file succeeds on unix and fails on windows rides along as context rather than as a second demand. punkshell's workaround is explicitly not removed if upstream fixes it - an upstream fix dates it rather than deletes it. Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com	5 days ago

Author

SHA1

Message

Date

Julian Noble

df83b21a24

bootsupport: replace mounted modpods by delete-then-place, and explain the windows catch-all (punkshell 0.27.4)

'make.tcl bootsupport' failed three times this session replacing the zip-based
punk::mix::templates modpod, always with:

error copying "<src>" to "<dst>": invalid argument

Root cause, demonstrated rather than inferred. A zipfs mount MEMORY-MAPS its archive
(tclZipfs.c CreateFileMappingW + MapViewOfFile), and windows refuses to overwrite a file
with a user-mapped section open - ERROR_USER_MAPPED_FILE (1224). Any holder blocks it: a
running punk shell that loaded the modpod, a src-mode session, or the build itself.
Reproduced directly: the same file copies fine unmounted, fails while zipfs-mounted, and
copies fine again once unmounted.

The message is a dead end BY CONSTRUCTION, which is why two earlier attempts at
characterising this (in commit messages and in the archived G-124 detail file - first "a
modpod make.tcl has itself mounted", then "a transient lock") were both wrong in different
ways. Tcl_WinConvertError maps only Win32 codes 0..267 and sends everything above them to
errorTable[1], which is EINVAL - so EVERY high-numbered windows error surfaces as "invalid
argument", naming neither cause nor remedy. Byte-identical code in 8.6 and 9.1b1.

FIX. ::punkboot::replace_possibly_mapped_file tries the ordinary copy and, on failure,
falls back to DELETE-THEN-PLACE, which windows does permit: unlinking a mapped file leaves
the holder reading its own mapping while new content lands at the name (measured: delete
succeeds while mounted, the mount keeps serving its old content afterwards). Replacement
content is staged to a sibling <target>.punkboot-new first, so a mid-sequence failure can
never leave the target missing; a 'broken' return - unlinked and unrestorable - is reported
as a build failure naming the file to restore by hand. This replaces a narrower prior
workaround that only recognised the already-identical case and otherwise recorded FAILED.

DIAGNOSIS. ::punkboot::mapped_file_hint fires when a genuine failure carries the catch-all
message and explains what it actually means and which process class to look for, instead of
leaving "invalid argument" bare. It stays silent for unrelated errors.

Verified on the real failure: the bootsupport run that has failed all session now reports
"(in-place overwrite refused - replaced by delete-then-place; target was memory-mapped, e.g
a mounted modpod)" and completes, with no hand-copy and no rerun. Helper-level checks cover
the unmapped path (plain copy, unchanged), the mapped path (recovers, content correct,
holder's mapping intact, no temp left behind) and both hint branches. Full suite 1167 tests,
1146 passed, 1 failure - core/tcl exec-14.3, the documented baseline.

Documented in src/bootsupport/AGENTS.md, including the general warning that 'invalid
argument' from ANY windows file operation in Tcl means "some windows error above 267" and
must never be read at face value.

Also drafts G-132 (user-approved): the errno catch-all is upstream's defect, not ours, and
deserves reporting. The goal is deliberately shaped so an AGENT DRAFTS AND THE DEVELOPER
SUBMITS - no account use, no web form, no API - following the G-039 precedent, with the
submission-ready text staged in TEMP_REFERENCE and the finding, reproducer, eventual ticket
URL and disposition kept in the tracked detail file, because TEMP_REFERENCE is one
'git clean -xdf' from gone. The report's claim is deliberately narrow: the errno conversion
is plainly wrong, while the related fact that 'file copy -force' over a mapped file succeeds
on unix and fails on windows rides along as context rather than as a second demand.
punkshell's workaround is explicitly not removed if upstream fixes it - an upstream fix
dates it rather than deletes it.

Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com

5 days ago

1 Commits (9f4c44454e3e07b6cee6f824c0190e4d4f207524)