-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
fix: package hash bug #17094
fix: package hash bug #17094
Conversation
This is not the best fix as it duplicates code.
.handle = iterable_dir.dir, | ||
}; | ||
}; | ||
defer tmp_directory.closeAndFree(gpa); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this double closeAndFree
tmp_directory
(since the original defer
is still active)? And the first tmp_directory
won't ever be closeAndFree
d?
@@ -608,6 +608,20 @@ fn fetchAndUnpack( | |||
// I have not checked what buffer sizes the xz decompression implementation uses | |||
// by default, so the same logic applies for buffering the reader as for gzip. | |||
try unpackTarball(gpa, prog_reader.reader(), tmp_directory.handle, std.compress.xz); | |||
|
|||
tmp_directory = d: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why only reopen in the application/x-xz
case? Wouldn't this affect all the other cases too?
@@ -608,6 +608,20 @@ fn fetchAndUnpack( | |||
// I have not checked what buffer sizes the xz decompression implementation uses | |||
// by default, so the same logic applies for buffering the reader as for gzip. | |||
try unpackTarball(gpa, prog_reader.reader(), tmp_directory.handle, std.compress.xz); | |||
|
|||
tmp_directory = d: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely need an explainer comment detailing why this is needed (and that it's effectively a workaround for a potential IterableDir.Iterator/Walker bug).
cleaner workaround coming as part of #17392 |
This is not the best fix atm as it duplicates code.
See #17064