Untar'ing archive to VirtioFS volume fails to create symlinks #6277
Comments
|
And I try Output: And I try to disable [Experimental Features] -> [Enable VirtioFs accelerated directory sharing], everything works fine. So weird.
|
|
Issues go stale after 90 days of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
|
For tar, this only appears to happen when the symlink target lives in a different directory. Here's a shell script that provides a minimal reproducible example. Note that this only works when the directory is a volume mounted from the host. # Create the directory structure that triggers the bug.
mkdir demo
touch demo/src
mkdir demo/subdir
( cd demo/subdir && ln -s ../src ./dst; )
# Create the archive and remove the source files.
tar -czvf demo.tgz ./demo
rm -rf ./demo
# Attempt to unpack the archive.
tar -xvf demo.tgzThe output will look something like this: The extracted result is so broken that |
|
Ah! The root cause appears to be When unpacking a symlink, tar first creates a symlink placeholder, creates the target, then replaces the placeholder with a real symlink. However, on VirtioFS, calling #include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
int main(int argc, char **argv) {
char *file_name = (argc > 1 ? argv[1] : "demo");
int rtn = openat(AT_FDCWD, file_name, O_RDWR|O_CREAT|O_EXCL, 000);
if ( rtn == -1 ) {
printf("rtn = %d; errno = %d, %s\n", rtn, errno, strerror(errno));
return errno;
} else {
printf("OK\n");
}
return 0;
}When you create a file on VirtioFS, it fails. Anywhere else it works as expected. |
|
I saw a similar issue, and workaround, with sed in the Docker forum. Allegedly, a patch was created for sed:
Could this be reported upstream to untar? |
|
/remove-lifecycle stale This still appears to repro as described above as of Docker Desktop 4.12.0 |
|
There hasn't been any activity on this issue for a long time. Prevent issues from auto-closing with a /lifecycle stale |
|
I can still reproduce it on 4.14.1 like in the original report. /remove-lifecycle stale |
|
@dserodio, have you seen? (Edit: Experimental MacOS builds related to VirtioFS not handling permissions) |
|
There hasn't been any activity on this issue for a long time. Prevent issues from auto-closing with a /lifecycle stale |
|
I've run into this with abiosoft/colima (which uses Code-Hex/vz) as well as with Docker Desktop. From looking at the APIs vz uses to set up virtiofs shares, it doesn't seem like this behavior is controllable. https://developer.apple.com/documentation/virtualization/shared_directories
Unfortunately these policies (specifically the second one) break existing widely deployed software, like GNU tar. |
|
/lifecycle frozen |
|
Possibly the same issue than recorded here: #6614 This is really a showstopper. I am developing a buildroot system and cannot use virtiofs at all because it uses these kind of symlinks during the build process. |
|
Still reproducible with |
|
I just tried 4.26.0 after running into this issue with 4.24.0 and I was able to successfully untar an archive containing symlinks to a VirtioFS volume using docker version 4.26.0! |
|
Still reproducible with 4.25.2, untar or sed was successfully when upgrade to 4.26.0! |
|
Can confirm. Updating from docker desktop 4.25.2 to 4.26.0 fixed this issue for me. |
Expected behavior
Un-
tar'ing an archive with symlinks in it to a VirtioFS file share location results in them being created.Actual behavior
tarreports permissions errors and the files end up getting created as zero byte files with no allowed permissions.Example:
Then
In this example,
katexis a symlink in the archive.Information
Output of
/Applications/Docker.app/Contents/MacOS/com.docker.diagnose checkSteps to reproduce the behavior
Here's the repro:
docker run -it --rm -v $(pwd):/test mcr.microsoft.com/vscode/devcontainers/repos/microsoft/vscode:branch-main bashThis does not repro when VirtioFS is disabled, so this is specifically feedback for this experiment.
The text was updated successfully, but these errors were encountered: