Correctly detect final path when extracting multiple tarballs #4922
Conversation
There was a problem hiding this comment.
@Flamefire Rather than adding (more) binary blobs to the repo, can we create multi-0.0.tar.gz and multi-1.0.tar.gz dynamically in the test itself?
That probably even helps with exposing what's being tested, since the structure within these tarballs is now not visible.
This request is fueled by a recent example of binary blobs being abused.
I'm aware we have other binary blobs in here already, we should look into getting rid of those too.
Create an empty target folder so the extraction can change into the extracted folder.
The current implementation of `extract_file` detected folders/files from the first tarball when extracting the second. Due to the definition of `find_base_dir` it will then return the parent path (usually `builddir`) which is used as the `finalpath` for sources. This leads issues requiring workarounds in e.g. the Bundle easyblock where sources from all components are extracted into the same folder. Fix by storing the old state of the target folder and detect of extraction resulted in a single (top-level) folder.
Adapt for `extract_dir` now returning the subfolder which it previously did not because the downloaded tar file is in the same folder.
|
@boegel I replaced the added binaries by creating them in the test (replacing the commit to remove them from the history) I also replaced all uses of other binaries in that test. The test-method I added should be easily usable for other tests. What I noticed: Our |
The current implementation of
extract_filedetected folders/files from the first tarball when extracting the second.Due to the definition of
find_base_dirit will then return the parent path (usuallybuilddir)which is used as the
finalpathfor sources.This leads issues requiring workarounds in e.g. the Bundle easyblock
where sources from all components are extracted into the same folder.
Fix by storing the old state of the target folder and detect of
extraction resulted in a single (top-level) folder.
As part of this work I enhanced the documentation and test of find_base_dir and added tests for the expected and (previous) error cases of
extract_fileguess_start_dirdetects the fixed behavior already: If there is aprefix/<startdir>/<startdir>which doesn't existprefix/<startdir>is used insteadE.g. GTK3 has start_dir set manually for components due to this bug which would now lead to builddir/foo/foo
IMO trivial to detect/fix
Remark: It is possible to have
find_base_dirNOT change into the resulting directory which means we can do this explicitely when requested instead of undoing it. Not sure if anyone outside the main repo relies on that.