Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copy files using coreutils cp #595

Merged
merged 3 commits into from
Jun 7, 2024
Merged

Copy files using coreutils cp #595

merged 3 commits into from
Jun 7, 2024

Conversation

plobsing
Copy link
Contributor

@plobsing plobsing commented May 29, 2024

Unlike cat redirected to a file, cp sees both its input and output and can more readily know the details of its arguments. These details can sometimes be exploited to achieve zero-copy transfers when the OS and filesystem know how to do copy-on-write (e.g. clonefile on Mac, copy_file_range on Linux). uutils' cp will attempt to take advantage of these opportunities where possible (see: https://github.com/uutils/coreutils/blob/35232689366fb102854693b6bd6b6161901d192e/src/uu/cp/src/cp.rs#L2190 ).

We need to pass --no-preserve=mode in order for cp to create the files as writable; which is necessary as some of the copies we perform need to be mutated afterwards. Depending on the nature of the Bazel setup, action input files might be readable but not writable, so the default behaviour of cp to preserve the permissions from its input to its output in this case would cause our later mutations to fail.

Also convert one of the remaining references to the system's cat (rather than uutils') in order to also convert it to a call to cp.

Unlike `cat` redirected to a file, `cp` sees both its input and output
and can more readily know the details of its arguments. These details
can sometimes be exploited to achieve zero-copy transfers when the
OS/filesystem can do copy-on-write (e.g. `clonefile` on Mac,
`copy_file_range` on Linux). uutils' `cp` will attempt to take
advantage of these opportunities where possible (see:
https://github.com/uutils/coreutils/blob/35232689366fb102854693b6bd6b6161901d192e/src/uu/cp/src/cp.rs#L2190
).

This is a slight behaviour change with respect to permissions and file
modes: `cp` preserves them while `cat` naturally does not. If file
metadata erasure is an important property of this code (I don't think it
is, but LMK) `cp` could be instructed to use the default file mode/permission
using the `--no-preserve` flag.

Also convert the one of the remaining references to the system's `cat`
(rather than uutils') to also convert it to a call to `cp`.
@thesayyn
Copy link
Collaborator

Thanks for the detailed write up. I never got cp working with Bazel permissions, mode.

@plobsing
Copy link
Contributor Author

Thanks for the detailed write up. I never got cp working with Bazel permissions, mode.

Looks like I failed to get it working too. It seems I overlooked the fact that oci-layout needs to be writable in order to accept later updates. Got it working locally (MacOS) now.

@thesayyn
Copy link
Collaborator

My nightmares came alive again, bonus points if you could get it working. :)

We don't want it ever and it seems to be breaking things.
@plobsing
Copy link
Contributor Author

plobsing commented Jun 2, 2024

OK, despite my best efforts, I couldn't get this latest instance to repro locally, but I did manage to run the workflow in my fork to get a repro. And based on that, it seems that if we pass --no-preserve=mode consistently everywhere, it works. PTAL.

@thesayyn thesayyn merged commit 333a982 into bazel-contrib:2.x Jun 7, 2024
14 checks passed
@plobsing plobsing deleted the 2.x branch June 7, 2024 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants