Skip to content

support tar.gz where files are prefixed by "./" - #27

Closed
davidB wants to merge 3 commits into
jaemk:masterfrom
davidB:bug/strip_dot_prefix
Closed

support tar.gz where files are prefixed by "./"#27
davidB wants to merge 3 commits into
jaemk:masterfrom
davidB:bug/strip_dot_prefix

Conversation

@davidB

@davidB davidB commented Aug 16, 2019

Copy link
Copy Markdown

To allow self_update to use .bin_name("f1.txt") on :
archive are created like:

tar -czvf t_archive.tar.gz -C t_archive .
a .
a ./f1.txt

like (existing) for archive created like:

cd t_archive
tar -czvf ../t_archive-2.tar.gz  *
a f1.txt

PS: calling .bin_name("./f1.txt") failed

@davidB

davidB commented Nov 11, 2019

Copy link
Copy Markdown
Author

the error on windows is random, sometime present, sometime no-error and in various place. I'm not a windows FS expert. Any suggestion ?

jaemk added a commit that referenced this pull request Sep 2, 2026
`tar -czf app.tar.gz -C dir .` stores every entry as `./name`, while
`tar -czf app.tar.gz *` stores it as `name`. The lookup in `extract_file` was an exact
path match on both the tar and zip arms, so the first archive failed with "Could not find
the required path in the archive" even though the file was there, and the caller has no
way to know which invocation produced the release artifact.

Both arms now compare through `archive_path_matches`, which ignores a leading `./` on
either side, so a `./`-prefixed request also matches a plainly-named entry. Interior
components are compared exactly, so a same-named file in a subdirectory cannot be selected
by accident.

Reported in #27.

Also pins two contracts that had no coverage: the github asset download URL comes from the
API `url` field (not `browser_download_url`), and the download request carries
`Accept: application/octet-stream`. Together those are what make a private release asset
reachable, and a flip between the two URL fields has broken downloads before (#77).
jaemk added a commit that referenced this pull request Sep 2, 2026
`tar -czf app.tar.gz -C dir .` stores every entry as `./name`, while
`tar -czf app.tar.gz *` stores it as `name`. The lookup in `extract_file` was an exact
path match on both the tar and zip arms, so the first archive failed with "Could not find
the required path in the archive" even though the file was there, and the caller has no
way to know which invocation produced the release artifact.

Both arms now compare through `archive_path_matches`, which ignores a leading `./` on
either side, so a `./`-prefixed request also matches a plainly-named entry. Interior
components are compared exactly, so a same-named file in a subdirectory cannot be selected
by accident.

Reported in #27.

Also pins two contracts that had no coverage: the github asset download URL comes from the
API `url` field (not `browser_download_url`), and the download request carries
`Accept: application/octet-stream`. Together those are what make a private release asset
reachable, and a flip between the two URL fields has broken downloads before (#77).
@jaemk

jaemk commented Sep 2, 2026

Copy link
Copy Markdown
Owner

Hi @davidB, fixed in #211: extract_file now ignores a leading ./ on either side, so an archive built with tar -czf a.tar.gz -C dir . (entries stored as ./f1.txt) resolves bin_name("f1.txt"), and a ./-prefixed path works as well. Only the leading ./ is ignored, so a same-named file in a subdirectory still cannot be selected by accident. Thanks for the report and the reproduction, closing in favor of that change.

@jaemk jaemk closed this Sep 2, 2026
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 this pull request may close these issues.

2 participants