mkDummySrc: preserve mode and then make writeable separately #964
Conversation
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
cole-h
force-pushed
the
mkDummySrc-preserve-xattrs
branch
from
b34171d to
e426c14
Compare
`--no-preserve=mode` causes `cp` to attempt to clear out the xattrs, which involves calling the fsetxattr syscall to set the "system.posix_acl_access" xattr. A previous attempt used `--no-preserve-mode` + `--preserve=xattr` to prevent needing to change any xattrs at all, but this doesn't work when `cp` is built without xattr support. So instead we just create the effect of `--no-preserve=mode` without using that flag: making `$out` writeable, recursively. Without this, builds can fail when using macOS's Virtualization.framework to share the store into a Linux VM, because its implementation of virtiofs doesn't seem to support xattrs. Specifically, this fixes building crane derivations with the Native Linux Builder.
cole-h
force-pushed
the
mkDummySrc-preserve-xattrs
branch
from
e426c14 to
71d917b
Compare
cole-h
changed the title
dpc
reviewed
Jan 29, 2026
| mkdir -p $out | ||
| cp --recursive --no-preserve=mode,ownership ${cleanSrc}/. -t $out | ||
| cp --recursive --no-preserve=ownership ${cleanSrc}/. -t $out | ||
| chmod +w -R $out |
Contributor
There was a problem hiding this comment.
The exact effect of +w seems to be umask-dependent. Is that OK? Should it use more explicit way of setting the permissions?
Owner
There was a problem hiding this comment.
Looking at the generic stdenv setup (what runCommand eventually delegates to) it doesn't seem like umask is set (to something different than its default) so I don't imagine it would affect things here?
Either way if we get this wrong builds will fail if we try to clobber the files. Once the derivation finishes the write permissions will get stripped from the store path
ipetkov
reviewed
Jan 30, 2026
Owner
ipetkov
left a comment
ipetkov
left a comment
There was a problem hiding this comment.
Thanks for the contribution! Pushed a comment to note that the chmod is "load bearing" here
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
--no-preserve=modecausescpto attempt to clear out the xattrs,which involves calling the fsetxattr syscall to set the
"system.posix_acl_access" xattr.
A previous attempt used
--no-preserve-mode+--preserve=xattrtoprevent needing to change any xattrs at all, but this doesn't work when
cpis built without xattr support. So instead we just create the effectof
--no-preserve=modewithout using that flag: making$outwriteable,recursively.
Without this, builds can fail when using macOS's Virtualization.framework
to share the store into a Linux VM, because its implementation of virtiofs
doesn't seem to support xattrs.
Specifically, this fixes building crane derivations with the Native
Linux Builder.
Motivation
Checklist
docs/API.md(or general documentation) with changesCHANGELOG.md