@htjain I started working on this a while back, but have too many other higher priorities now to finish in a reasonable amount of time.

If you were interested in taking it over, we could move it forward.

@rhatdan I can take it up. #15730 this PR you are talking about ?

Yes. It is all yours.

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

@htjain any progress?

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

@flouthoc PTAL

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

@rhatdan I'd like to look into this.

@danishprakash Thanks assigned it to you :)

While triaging, I found some issues with what we're trying to achieve which I'd like to clear before I move on. It looks like

In docker cp, if you don't specify the --follow-link flag, docker would just copy the link and not the destination file. But if you do specify that flag, it would follow the link and copy the target to the destination.

$ docker run -d --rm -it --name test opensuse/tumbleweed bash

$ ls -al /tmp/file
/tmp/file -> /home/user/config/target

$ docker cp /tmp/file test:/tmp/file
$ docker exec test ls -al /tmp/file
/tmp/file -> /home/user/config/target 	# this doesn't exist of course

$ docker cp --follow-link /tmp/file test:/tmp/file
$ docker exec test ls -al /tmp/file
/tmp/file 								# with the contents for the symbolic link target

Now, podman, by default, follows the link without the --follow-link flag. So the question would be, do we change the current cp behavior to conform to docker's and add the --follow-link flag to do what it does right now. Or we leave it as is and document the behaviour? Or I might've missed something and the above is not right, in which case, I'd request either @rhatdan or @flouthoc to corroborate this once, thanks!

Okay podman indeed by default follows the symlink, i'd say we should default to how docker does and introduce a --follow-link, my only concern is that this is a breaking change and might break old users.

Again my vote is to default how docker does it but lets wait for others to take a look.

@rhatdan @containers/podman-maintainers WDYT ?

+1 to the Docker behavior. It is safer to not follow symlinks by default

Agreed. Docker compat is also a compelling reason to change the default.

That sounds great but as @flouthoc said, I'm also concerned that this is a breaking change and might break existing workflows. Either way, I'll start looking into the changes.

We need a boolean to change the default globally in containers.conf, then users who want the preivous default can customize their environment.

Tried a sample implementation here which included changes to both buildah and podman. The idea is to maintain the symlink even if the target isn't present on the container which would inevitably lead to an error when accessed. This is docker's behaviour too.

While passing --follow-link flag, podman would continue to do what it currently does.

We need a boolean to change the default globally in containers.conf, then users who want the preivous default can customize their environment.

I can go ahead and finalize the PRs in both the repos if the approach above sounds reasonable. Thoughts?

yes please open the PRs so we can comment on them

I noticed that the PR in buildah got stale. In the meantime, could we introduce the --follow-link and -L flags just to improve compatibility with docker-based scripts that use them (e.g. mflowgen)? This shouldn't break any existing workflow.

Are you suggesting a dummy flag so that podman doesn't complain?

Exactly, mflowgen extensively uses docker cp -aL <...>, which results in podman complaining of non-existent -L flag

Perhaps @rhatdan @giuseppe can chime in here. Either way, it'd be nice if we can move ahead on the PR, waiting on review.