summaryrefslogtreecommitdiff
path: root/pkg/copy
Commit message (Collapse)AuthorAge
* support container to container copyMehul Arora2021-07-27
| | | | | | | | | Implement container to container copy. Previously data could only be copied from/to the host. Fixes: #7370 Co-authored-by: Mehul Arora <aroram18@mcmaster.ca> Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* podman cp: support copying on tmpfs mountsValentin Rothberg2021-03-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Traditionally, the path resolution for containers has been resolved on the *host*; relative to the container's mount point or relative to specified bind mounts or volumes. While this works nicely for non-running containers, it poses a problem for running ones. In that case, certain kinds of mounts (e.g., tmpfs) will not resolve correctly. A tmpfs is held in memory and hence cannot be resolved relatively to the container's mount point. A copy operation will succeed but the data will not show up inside the container. To support these kinds of mounts, we need to join the *running* container's mount namespace (and PID namespace) when copying. Note that this change implies moving the copy and stat logic into `libpod` since we need to keep the container locked to avoid race conditions. The immediate benefit is that all logic is now inside `libpod`; the code isn't scattered anymore. Further note that Docker does not support copying to tmpfs mounts. Tests have been extended to cover *both* path resolutions for running and created containers. New tests have been added to exercise the tmpfs-mount case. For the record: Some tests could be improved by using `start -a` instead of a start-exec sequence. Unfortunately, `start -a` is flaky in the CI which forced me to use the more expensive start-exec option. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Enable golint linterPaul Holzinger2021-02-11
| | | | | | | | Use the golint linter and fix the reported problems. [NO TESTS NEEDED] Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
* SpellingJosh Soref2020-12-22
| | | | Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
* remote copyValentin Rothberg2020-12-18
| | | | | | | | | | | | | | Implement `podman-remote cp` and break out the logic from the previously added `pkg/copy` into it's basic building blocks and move them up into the `ContainerEngine` interface and `cmd/podman`. The `--pause` and `--extract` flags are now deprecated and turned into nops. Note that this commit is vendoring a non-release version of Buildah to pull in updates to the copier package. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* pkg/copy: introduce a CopierValentin Rothberg2020-12-09
| | | | | | | Introduce a `Copier` object to separate the copy-rule enforcement from copying. That allows for a better error reporting of the REST API. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* archive: move stat-header handling into copy packageValentin Rothberg2020-12-09
| | | | | | | | Move handling the stat header into `pkg/copy`. All copy-related should ideally be located in this package to increase locality and reduce scattering where possible. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* pkg/copy: add parsing APIValentin Rothberg2020-12-09
| | | | | | | | Add an API for parsing user input into a possibly specified container and path. This allows for sharing the parsing code between the local and the remote client (and bindings) in the future. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* rewrite podman-cpValentin Rothberg2020-12-04
* Add a new `pkg/copy` to centralize all container-copy related code. * The new code is based on Buildah's `copier` package. * The compat `/archive` endpoints use the new `copy` package. * Update docs and an several new tests. * Includes many fixes, most notably, the look-up of volumes and mounts. Breaking changes: * Podman is now expecting that container-destination paths exist. Before, Podman created the paths if needed. Docker does not do that and I believe Podman should not either as it's a recipe for masking errors. These errors may be user induced (e.g., a path typo), or internal typos (e.g., when the destination may be a mistakenly unmounted volume). Let's keep the magic low for such a security sensitive feature. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>