Skip to content
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

Extracting self-referential hard link should work #127

Closed
StefanKarpinski opened this issue Feb 1, 2022 · 0 comments · Fixed by #130
Closed

Extracting self-referential hard link should work #127

StefanKarpinski opened this issue Feb 1, 2022 · 0 comments · Fixed by #130

Comments

@StefanKarpinski
Copy link
Member

https://discourse.julialang.org/t/using-artifactutils-add-artifact-throws-ioerror/75568

@StefanKarpinski StefanKarpinski changed the title Extracting circular links should work Extracting self-referential hard link should work Feb 9, 2022
StefanKarpinski added a commit that referenced this issue Feb 9, 2022
This is a weird construction: an entry for a file followed by a hardlink
to what that file as its target and with the same path. The hardlink
copies the content of its target and creates a file with the "new" path
and mode, which happens in this case to be the same path as the original
file. The effect of this construction is to change the permissions of an
previous file entry. We could diallow this since it's odd, but based on
the bug report it is something `tar` can generate and the other tarball
reading methods like `tree_hash` and `rewrite` already just work because
the logic is simply to copy the contents of an existing node with a new
path and mode and for a sane tree data structure, you can just overwrite
an arbitrary node. The file system is wonkier and the change in logic
here is merely to ensure that the old file isn't deleted too early.
StefanKarpinski added a commit that referenced this issue Feb 10, 2022
This is a weird construction: an entry for a file followed by a hardlink
to what that file as its target and with the same path. The hardlink
copies the content of its target and creates a file with the "new" path
and mode, which happens in this case to be the same path as the original
file. The effect of this construction is to change the permissions of an
previous file entry. We could diallow this since it's odd, but based on
the bug report it is something `tar` can generate and the other tarball
reading methods like `tree_hash` and `rewrite` already just work because
the logic is simply to copy the contents of an existing node with a new
path and mode and for a sane tree data structure, you can just overwrite
an arbitrary node. The file system is wonkier and the change in logic
here is merely to ensure that the old file isn't deleted too early.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant