Repository navigation
linux: one wrap, one working directory, and no object taken for the same install - #655
Merged
Merged
Conversation
…ame install Since the walk gives the thread back, a wrap starts over when it finds another configuration object than it started with. Two things got past that. A host that changed its working directory in a turn of the walk got a command put together from both: a `.` bound back from where it had gone to, over denies walked from where it was. And initialize() keeps the caller's own object, so reset() and initialize() with it again looked like no change at all. A wrap now also starts over when a configuration has been installed since it began, by a count, and when the working directory has changed.
… well The Linux wrapper awaits once more, for its scan for dangerous names, after the manager's last check, and resolves relative entries on both sides of that. It now notes the working directory at its start and throws right after the scan if that has changed, before anything is left on the host. The manager starts the wrap over.
Merged
ronleizrowice-ant
added a commit
that referenced
this pull request
Oct 7, 2026
New to the bundle: #655, #660 and the version. #643, #639 and #630 come as squashes of what it held; in the one block git marks, the workflow's, it keeps its own side, which has the checksummed bun as well. Two cases of #655 compare two wrapped commands. Here a wrap that names mount points names a manifest of its own (#584), so the cases take that name out before they compare.
This was referenced Oct 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two ways past the check "one wrap, one configuration". Both came with the walk in turns (#628), which is on
mainand in no release.What was wrong
A wrap starts over when it finds another configuration object than it started with.
.as a write root) is resolved against it wherever it is read. A host that callschdir()in a turn of the walk gets a command put together from both directories: denies walked from the old one,.bound back from the new one. Where the new one lies inside a folder a**rule denies, what the rule matches there comes back readable.initialize()keeps the caller's own object, soreset()andinitialize()with it again, during a wrap, looks like no change. A file written before that is not denied, against linux: a wrap that starts over reads the disk again #644's invariant.What changes
One predicate in place of the identity test, in the walk's steps and after the last
await. A wrap also starts over when:initialize()andupdateConfig();process.cwd()has changed (5 to 15 ns a call on Node 22 and Bun 1.4). A directory that was removed counts as a change.The Linux wrapper awaits once more after that, for its scan for dangerous names, and resolves relative entries on both sides of it. It notes the working directory at its start and throws
WorkingDirectoryChangedright after the scan if that has changed, before anything is left on the host; the manager starts over. (Second commit.)Each new term only makes a wrap start over more often. The bound after two restarts is as it was for the walk; the scan still gives the thread back.
Known limit
Mutating the object handed to
initialize()is still not seen. Cloning it there would lose its function-valued fields.Measured
Real bubblewrap, a walk over 400,150 files, 3 runs a case:
mainchdir()into a folder a**rule denies,allowWrite: ['.']reset()andinitialize(sameObject)chdir()during the scan (a stand-in that takes 0.4 s),allowWrite: ['.']Six rules over the same tree, undisturbed: 1.0 s on both.
Testing
Four new cases:
chdir()in the middle of the walk, in its last listing and during the scan, and the second install. All fail onmain's source. Six mutations: five fail a test. The sixth, dropping the object test, survives: every install counts now, and the test stays for the paths that set the configuration toundefined.