files listing: serve a mode/executable field so clones can preserve ALL file modes

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed feature request

Colby Knox · 1mo ago ·closed by Colby Knox

Optional follow-through from adom-wiki-cli#40 (John's clone-edit-publish trap: clones land everything 644, the registry mandates ./install.sh, so republishing shipped un-runnable installs three times on hydrogen-bootstrap).

The trap itself is closed client-side in CLI 1.7.15: pkg pack/publish now chmod +x the mandated-executable files (scripts.install/uninstall targets + bin/ entries) on disk before tar reads the modes, and repo clone restores the same set from the cloned manifest, both with an EXEC_BIT_NORMALIZED hint. Note the server could not have normalized this itself: the tarball is sealed client-side, so pack time is the only choke point that fixes every publisher.

What remains and why it is yours: GET /api/pages/:ref/files entries carry {hash, lastCommit, name, path, size, type} but no mode, so a clone can only repair the files a manifest MANDATES as executable. Any other executable in a repo (helper scripts, prepublish-check.sh, test runners) still lands 644. One field (mode, or a boolean executable) on the listing rows and the CLI restores full fidelity for everything.

Low urgency: the load-bearing case is closed. Worth doing when the listing route is next touched.

2 Replies

Colby Knox · 1mo ago

Shipped to prod: files listing rows now carry mode (100644/100755/120000/040000) and an executable boolean. git ls-tree already reported the mode; the parser was discarding it. Verified on prod against hydrogen-bootstrap, the page that motivated the trap. CLI can restore full mode fidelity on clone whenever it picks the field up.

Colby Knox · 1mo ago

CLI picked the field up: adom-wiki 1.7.20 (released, latest). Clone applies each row's mode/executable, so every executable survives a clone once the tree actually carries the bit. One deliberate override, verified on hydrogen-bootstrap itself: the mandated-set repair (#40) stays unconditional, because repos STORE their ./-invoked scripts as 100644 today and honoring that verbatim would have resurrected the original trap on the page that motivated it (install.sh lands 755 by mandate, prepublish-check.sh lands 644 matching the repo). The reason trees are mode-less is the push route: multipart /files cannot transmit modes, filed as #165; once it can, the CLI sends the bit and the round trip closes end to end.