Created attachment 8271 [details] ZIP of Dockerfile examples that highlight the problem The tar command in BusyBox deviates in behavior from its GNU counterpart when, if you have a directory, "thing/", with a file, "thing.bar", in it ("thing/thing.bar") and create an archive with the following command: "tar -cvf foo.tar thing/thing.bar" then attempt to extract it with "tar -xvf foo.tar -C / thing". It will fail with an error saying "tar: thing: not found in archive". The same tar extract command will work, however, _if_ the tar archive was created in this way: "tar -cvf for.tar thing/" (specifying the directory rather than just an object in it). It _is_ possible to extract "thing.bar" directly from the first-mentioned tar using this tar extract: "tar -xvf foo.tar -C / thing/thing.bar". GNU tar, however, is able to extract fine in all the scenarios I listed. It has no problem running "tar -xvf foo.tar -C / thing" on a tar created with "tar -cvf foo.tar thing/thing.bar". I am curious whether this is a bug in that it doesn't operate in the same way that GNU tar seems to, or if this is a conscious decision on BusyBox's part. I have attached a file, "tar-examples.zip" with three Dockerfiles that will exhibit the scenarios described.
Further clarification... In the failure cases mentioned, the contents do still extract, it just causes the tar command to fail with the "not found in archive" message. And, since it's a non-zero exit code, using the command in something like a Dockerfile will cause the "docker build" to fail.
Given that the contents extract, and then tar exits with a non-zero exit code, I feel pretty safe calling this a bug.
To create a tarball that reproduces the issue you can use the following commands: ~# cd /tmp/ /tmp# mkdir test /tmp# touch test/a /tmp# tar zcvf test.tar.gz test/a test/a /tmp# mkdir test2 /tmp# tar zxvf test.tar.gz -C test2/ test test/a tar: test: not found in archive The tar works fine if it is created with the following command: /tmp# tar zcvf test.tar.gz test test/ test/a In attaching a patch (based on busybox v1.31.1) that seems to fix the issue.
Created attachment 9281 [details] Patch for busybox 1.31.1