LinuxContainer: Support copying directories#571
Merged
dcantah merged 1 commit intoapple:mainfrom Mar 6, 2026
Merged
Conversation
Now that the static linux SDK we use has libarchive linked against it, we can finally live our dream (/s) of supporting copying directories in/out a little easier. This was.. kind of annoying. I think the very simple route of writing archive to guest/host -> streaming over grpc is simplest, but on the guest end we have a couple problems: 1. The VMs rootfs is read only today always, which is a good thing to me and I don't want to change if we don't have to. 2. Writing the archive to the containers rootfs temporarily could work, but it's a bit weird, and the user can make the containers rootfs readonly which would screw that plan. 3. We could write it to /run or /tmp, but they're tmpfs and dealing with the headache of the user possibly tarring an enormous dir is one I don't want to care about. So, that leaves us with the (truthfully better to me) approach of trying to write the tar data directly to the host and skipping grpc which kinda forces us to have a temp spot. Because of that, I made it such that we pass a port number from host<->guest, and transfer the actual data (either the single file or tarred dir contents) over the vsock port instead. The stream is kinda clunky, but it just serves as a means to exchange metadata and a "we're done" signifier.
dcantah
force-pushed
the
copy-dir-support
branch
from
b65afd9 to
a2a62f7
Compare
JaewonHur
approved these changes
Mar 6, 2026
| /// | ||
| /// For COPY_OUT, the `onMetadata` callback is invoked when the guest sends | ||
| /// metadata (is_archive, total_size) before data transfer begins. | ||
| /// For COPY_IN, `onMetadata` is not called. |
Contributor
There was a problem hiding this comment.
Isn't it called anyway? Couldn't find different path for COPY_IN.
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
2 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.
Now that the static linux SDK we use has libarchive linked against it, we can finally live our dream (/s) of supporting copying directories in/out a little easier. This was.. kind of annoying. I think the very simple route of writing archive to guest/host -> streaming over grpc is simplest, but on the guest end we have a couple problems:
So, that leaves us with the (truthfully better to me) approach of trying to write the tar data directly to the host and skipping grpc which kinda forces us to have a temp spot. Because of that, I made it such that we pass a port number from host<->guest, and transfer the actual data (either the single file or tarred dir contents) over the vsock port instead. The stream is kinda clunky, but it just serves as a means to exchange metadata and a "we're done" signifier.