podman cp, with volumes + tarfile + exact name match, is a NOP

[edsantiago]

Looks like an obscrure corner case of #3059

# podman volume create v
v
# vdir=$(podman volume inspect -f '{{.MountPoint}}' v)
# ls -la $vdir
total 8
drwxr-xr-x. 2 root root 4096 Jul 10 17:55 .
drwx------. 3 root root 4096 Jul 10 17:55 ..

Now create a tarball:

# mkdir mysubdir
# echo this is a file >mysubdir/myfile
# tar cf mysubdir.tar mysubdir

Then create a container, mounting the volume using the same name as the subdirectory in the tarball. podman cp of the tarball into the container will silently fail:

# podman create --name foo -v v:/mysubdir alpine
70f1ad4ac78d5933fd2e0ebefdeb46435c38da382c06b77de00073e63f18984b
# podman cp - foo:/ < mysubdir.tar
# ls -la $vdir/
total 8
drwxr-xr-x. 2 root root 4096 Jul 10 18:02 .
drwx------. 3 root root 4096 Jul 10 17:55 ..

cp into the volume subdirectory works:

# podman cp - foo:/mysubdir < mysubdir.tar
# ls -l $vdir/
total 4
drwxr-xr-x. 2 root root 4096 Jul 10 17:57 mysubdir
# ls -l $vdir/mysubdir/
total 4
-rw-r--r--. 1 root root   15 Jul 10 17:57 myfile

podman-1.4.4-3.fc30

[rhatdan]

@QiWang19 PTAL

[QiWang19]

the issue is after extracting the tar archive, if it returns a folder has the same name with the volume, podman copies it to the containerMountpoint/volumename not the volumePath. Is it possible to fix this?

[mheon]

We may want to look into having podman cp join the mount namespace of the container - it would solve all these pathing gotchas...

[QiWang19]

how to let podman cp join the mount namespace?

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[rhatdan]

@QiWang19 @jwhonce I think we talked about this a while ago, but we still have not pursued it, correct?

[mheon]

I think we may want to close this one and open a tracker for a rewrite of cp

[mheon]

I'll leave it open until that happens, though. Better than losing it.

[jwhonce]

I thought we had a card for the rewrite but I cannot find it now. @mheon did it get deleted?

[vrothberg]

Friendly ping.

[rhatdan]

@QiWang19 Any chance you can look at this?

[QiWang19]

I had a PR to fix this by mounting the volumes but hasn't been merged for security reasons.
We have a card for rewriting the podman cp, may be this should be fixed after a new version of podman cp.https://issues.redhat.com/browse/RUN-531

[rhatdan]

@QiWang19 Could you talk to @nalind on this to see if his work on COPY can be used to fix this.

[rhatdan]

@nalind @QiWang19 Any progress?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@jwhonce I think this one is needed to bubble up?

[vrothberg]

@nalind, iterating on #3550 (comment): What's your take on passing a map to translate paths to the copier?

Note: copying to running containers works. The data is also copied up to the volume once a created container starts.

[nalind]

Rename maps are an option that the API provides, but volume are located outside of the rootfs on the host, so Put chrooting into the rootfs to write things is going to thwart efforts to solve this with that.

You could try starting Put multiple times, once per volume, with each invocation reading from a pipe, and examine each item in the stream that Get creates as it goes. You could then adjust Names and Linknames in headers read from Get, factoring in where they should end up, and feed the headers and their corresponding file contents into right Put pipe.

Hard links will complicate that, though, since it's possible that hard links would refer across rootfs/volume boundaries, and Put can't create a hard link to a file that it can't access.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@edsantiago @vrothberg @nalind What is the latest on this one?

[edsantiago]

Issue still present in main @ fe0bb28

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@mheon Could you look at this one?

[edsantiago]

Still present in main @ a866a2f

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@flouthoc any chance to look at this?

[edsantiago]

Abandoning. This will never get fixed.