Skip to content
This repository was archived by the owner on Mar 27, 2024. It is now read-only.

Resolve symlink issue. #355

Merged
merged 2 commits into from
Apr 20, 2021
Merged

Conversation

intelzhongjie
Copy link
Contributor

If there is certain symlink in the container image like this:

/A --> /X/Y/Z

AND if the "/X/Y/Z" doesn't exists on the host OS, then the current
invocation to os.Stat will give errors saying that the "Could not
obtain size for /X/Y/Z". This is because that it will follow the
link to check the /X/Y/Z on the host. That is improper.

The proper behaviour should be:
From the perspective of the symlink inside the container image, the
valid target file it pointing to is always some "existing file" in
the container image.
From the perspective of the host OS, it should just respect the
"closure" of the file system inside the container image.

To resolve it, instead of the os.Stat, we can use os.Lstat which
will not follow the link to check the target file.

Signed-off-by: zhongjie [email protected]

If there is certain symlink in the container image like this:

/A --> /X/Y/Z

AND if the "/X/Y/Z" doesn't exists on the host OS, then the current
invocation to os.Stat will give errors saying that the "Could not
obtain size for /X/Y/Z". This is because that it will follow the
link to check the /X/Y/Z on the host. That is improper.

The proper behaviour should be:
From the perspective of the symlink inside the container image, the
valid target file it pointing to is always some "existing file" in
the container image.
From the perspective of the host OS, it should just respect the
"closure" of the file system inside the container image.

To resolve it, instead of the os.Stat, we can use os.Lstat which
will not follow the link to check the target file.

Signed-off-by: zhongjie <[email protected]>
@intelzhongjie
Copy link
Contributor Author

REPRO STEP:
test_symlink.zip
The attached zip package include the test data to repro the issue and verify the fix. To use it, just unzip it and cd to the sub folder to run the ./build.sh in each sub-folder to build the Docker images for compare.
After that, just run the command like this:

container-diff diff daemon://scratch:base0.0 daemon://scratch:base0.1 --type=file --json --no-cache
ERRO[0000] Could not obtain size for /tmp/scratch@sha256:5b479b1952dd61130f21d5d74dacb20b4c0dd9b04f8674c130507ed98fe4762a487663054/vendor: stat /tmp/scratch@sha256:5b479b1952dd61130f21d5d74dacb20b4c0dd9b04f8674c130507ed98fe4762a487663054/vendor: no such file or directory

@intelzhongjie
Copy link
Contributor Author

intelzhongjie commented Mar 16, 2021

The build error in https://travis-ci.org/github/GoogleContainerTools/container-diff/builds/762932232 are some conflicts between the expectation and actual result on certain symlinks (e.g. /usr/bin/cc, /usr/lib/cpp, /usr/lib/gcc/x86_64-redhat-linux/4.8.2/32/libasan.a, etc.) .
And that's just the new behavior of using Lstat instead of Stat. If you think OK, then I can update the tests/file_diff_expected.json accordingly.

What's your opinion?
@nkubala @tstromberg

Best regards!

@intelzhongjie
Copy link
Contributor Author

Updated the tests/file_diff_expected.json accordingly.

@intelzhongjie
Copy link
Contributor Author

@nkubala @tstromberg ping?

Copy link
Contributor

@nkubala nkubala left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for the fix @intelzhongjie!

@nkubala nkubala merged commit 15751cb into GoogleContainerTools:master Apr 20, 2021
@intelzhongjie
Copy link
Contributor Author

Thanks for your review @nkubala !
I'm very happy that I can give the contribution to your helpful tool!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants