Skip to content

Comments

Add container copy/cp command for host-container file transfer#1190

Open
simone-panico wants to merge 11 commits intoapple:mainfrom
simone-panico:main
Open

Add container copy/cp command for host-container file transfer#1190
simone-panico wants to merge 11 commits intoapple:mainfrom
simone-panico:main

Conversation

@simone-panico
Copy link
Contributor

@simone-panico simone-panico commented Feb 10, 2026

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update

Motivation and Context

Adds the container copy (aliased as cp) command to copy files between a running container and the local filesystem.

I saw #1023 and the feedback from @dcantah — the previous attempt relied on tar being installed inside the container.
This implementation takes the recommended approach:
file transfers go through the guest agent via the existing copyIn/copyOut methods on the core Containerization, with no dependency on container tooling.

Testing

  • Tested locally
  • Added/updated tests
  • Added/updated docs

@simone-panico simone-panico marked this pull request as ready for review February 10, 2026 21:22
@JaewonHur
Copy link
Contributor

Related to #232

@jglogan jglogan requested a review from dcantah February 11, 2026 23:20
@jglogan jglogan added storage issues and features associated with storage. labels Feb 11, 2026
@jglogan jglogan requested review from JaewonHur February 11, 2026 23:21
@jglogan jglogan modified the milestone: 2026-02 Feb 11, 2026
let request = XPCMessage(route: SandboxRoutes.copyIn.rawValue)
request.set(key: SandboxKeys.sourcePath.rawValue, value: source)
request.set(key: SandboxKeys.destinationPath.rawValue, value: destination)
request.set(key: SandboxKeys.fileMode.rawValue, value: UInt64(mode))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why UInt64 here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the set Method in XPCMessage.swift expects a UInt64

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to handle it differently? I looked at the code again and couldn't find a better option

@JaewonHur
Copy link
Contributor

JaewonHur commented Feb 17, 2026

CopyOut/CopyIn Scenarios: Current vs Docker Behavior

Scenario 1: src without /, dst without / (src must exist)

  • File, Directory → Non-existing:

    • Docker (desired): save as dst
    • Current: File is saved as dst, Directory is not supported.
  • File → File

    • Docker (desired): replace dst
    • Current: replace dst
  • Directory → File

    • Docker (desired): error
    • Current: Directory is not supported
  • File, Directory → Directory

    • Docker (desired): save under dst
    • Current: File returns error, Directory is not supported.

Scenario 2: src without /, dst with / (dst must be a directory if existing)

  • File → Non-existing:

    • Docker (desired): error no such directory
    • Current: dst is created and src file is saved under dst.
  • Directory → Non-existing:

    • Docker (desired): save as dst
    • Current: Directory is not supported.
  • File, Directory → Directory

    • Docker (desired): save under dst
    • Current: File is saved under dst. Directory is not supported.

Scenario 3: src with /, dst without / (src must be an existing directory)

  • Directory → Non-existing:

    • Docker (desired): save as dst
    • Current: Directory is not supported.
  • Directory → File

    • Docker (desired): error
    • Current: Directory is not supported.
  • Directory → Directory

    • Docker (desired): save under dst
    • Current: Directory is not supported.

Scenario 4: src with /, dst with / (src must be an existing directory & dst must be a directory if existing)

  • Directory → Non-existing:

    • Docker (desired): save as dst
    • Current: Directory is not supported.
  • Directory → Directory

    • Docker (desired): save under dst
    • Current: Directory is not supported.

@JaewonHur
Copy link
Contributor

JaewonHur commented Feb 18, 2026

Hi @simone-panico
Above I summarized the desired behavior and current behavior.

The bold italic phrases are what is different from desired behavior (i.e., docker) now, and can be addressed.

Below is general comments.

  1. Copying directory is not supported yet, we need to handle it later.
  2. If dst/, it would be better to check in command line if dst is directory if it exists.

@JaewonHur
Copy link
Contributor

Hi @simone-panico
Could you try this PR with apple/containerization#474, which supports copying directories.

You may need to build this project with local containerization (BUILDING.md), and wire up SandboxService.

@dcantah
Copy link
Member

dcantah commented Feb 19, 2026

@JaewonHur the change above does not allow copying directories. It adds a tar reader/writer that will be used to support this, but it's not in the change itself.

@simone-panico
Copy link
Contributor Author

If you’re interested, I could try to create a Directory Copier within containerization. It would also be a great challenge for me

@simone-panico
Copy link
Contributor Author

@JaewonHur @dcantah, I created apple/containerization#543 for clarity.

As soon as apple/containerization#474 is merged I think I could start with implementing the directory copying. What do you think?

@JaewonHur
Copy link
Contributor

Hi @simone-panico, sorry for the delay!

We have an internal discussion how to better support container cp, and want to pause this for now. We will definitely revisit this PR once every thing becomes clear! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

storage issues and features associated with storage.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants