New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
archive/zip: AddFS with a symlink results in an empty file #61875
Comments
CC @dsnet |
Of the options, encoding an empty file seems to be the worst. I'd argue for returning an error for the time being. It is generally more acceptable to convert an error into a properly handled case in the future, than the other way around. I'm not opposed to just ignoring non-regular files as well. There is an seldom used extension to zip that can encode Unix-specific files like symlinks, devices, etc., but it's not clear to me that we should implement that. I can imagine a community of helper |
Proposal for fs.ReadLinkFS seems promising. We could try to type assert it and then read from the source of the symlink, then fs.FS should work as expected. As you said from the choices we have returning an error is the most correct way. In the future if we support this the transition will be seamless. Iwill push a fix for the AddFS in archive/zip as well as fixing my open CL in archive/tar |
When a filesystem with symlinks is used to invoke AddFS the resulting file inside the zip archive is empty if the file is a symbolic link. In this case we can be explicit and return an error. Fixes golang#61875
When a filesystem with symlinks is used to invoke AddFS the resulting file inside the zip archive is empty if the file is a symbolic link. In this case we can be explicit and return an error. Fixes golang#61875
Change https://go.dev/cl/517475 mentions this issue: |
When a filesystem with non-regular files is used the resulting files inside the zip archive are empty. In this case we can be explicit and return an error. Fixes golang#61875
When a filesystem with non-regular files is used the resulting files inside the zip archive are empty. In this case we can be explicit and return an error. Fixes golang#61875
When a filesystem with non-regular files is used the resulting files inside the zip archive are empty. In this case we can be explicit and return an error. Fixes golang#61875
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes, this is a tip (1.22) only issue.
What did you do?
Tried to call AddFS with a fs.FS with symlinks.
What did you expect to see?
Either an error or the proper file contents.
What did you see instead?
Files that are symlinks result in an empty file inside the zip archive.
Had a discussion on this CL about symlink support in zip files.
We have the proposal for fs.ReadLinkFS that could somewhat make this possible to implement, but the proposal is currently on hold.
I see a couple options to be weighted:
zip warning: name not matched: ./dir/iamasymlink
but the zip gets created, skipping the symlinks.The text was updated successfully, but these errors were encountered: