Describe the bug
gh version 2.20.2 (2022-11-15)
Using 'gh package download' to replace a previously downloaded zip file, with a new zip of the same name, can result in a corrupted zip file.
This only happens if the hosted file size, to be downloaded, is smaller than the previous download.
The file size locally remains unchanged, implying that some of the old content remains in the local file.
This is a problem when I update a feature branch with a smaller zip asset.
Steps to reproduce the behavior
- Find a repo with a zip asset
- run e.g. "gh release download 2.7.3-feature%2Fblabla%2Fchange-to-blablabla --dir $HOME --repo company/our-repo --pattern '*.zip' --clobber"
- Identify the dowloaded file
- replace it with a larger file, e.g. using "dd if=/dev/zero of=identified-file.zip bs=1024 count=10240 conv=sync"
- re run the command from 2 and observe it is still 10MB
- unzip -t identified-file.zip reports zip is corrupt.
Expected vs actual behavior
The file should be of the same size as is on the server after it is downloaded and should not be corrupt.
Logs
$ gh release download v2.20.2 --clobber --repo cli/cli --pattern '*_amd64.zip'
$ ls -laF
...
-rw-r--r-- 1 d d 9619658 Dec 7 12:52 gh_2.20.2_windows_amd64.zip
...
$ dd if=/dev/zero of=gh_2.20.2_windows_amd64.zip bs=1024 count=10240 conv=sync
10240+0 records in
10240+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0565074 s, 186 MB/s
$ gh release download v2.20.2 --clobber --repo cli/cli --pattern '*_amd64.zip'
$ unzip -t gh_2.20.2_windows_amd64.zip
Archive: gh_2.20.2_windows_amd64.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of gh_2.20.2_windows_amd64.zip or
gh_2.20.2_windows_amd64.zip.zip, and cannot find gh_2.20.2_windows_amd64.zip.ZIP, period.
Describe the bug
gh version 2.20.2 (2022-11-15)
Using 'gh package download' to replace a previously downloaded zip file, with a new zip of the same name, can result in a corrupted zip file.
This only happens if the hosted file size, to be downloaded, is smaller than the previous download.
The file size locally remains unchanged, implying that some of the old content remains in the local file.
This is a problem when I update a feature branch with a smaller zip asset.
Steps to reproduce the behavior
Expected vs actual behavior
The file should be of the same size as is on the server after it is downloaded and should not be corrupt.
Logs
$ gh release download v2.20.2 --clobber --repo cli/cli --pattern '*_amd64.zip'
$ ls -laF
...
-rw-r--r-- 1 d d 9619658 Dec 7 12:52 gh_2.20.2_windows_amd64.zip
...
$ dd if=/dev/zero of=gh_2.20.2_windows_amd64.zip bs=1024 count=10240 conv=sync
10240+0 records in
10240+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0565074 s, 186 MB/s
$ gh release download v2.20.2 --clobber --repo cli/cli --pattern '*_amd64.zip'
$ unzip -t gh_2.20.2_windows_amd64.zip
Archive: gh_2.20.2_windows_amd64.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of gh_2.20.2_windows_amd64.zip or
gh_2.20.2_windows_amd64.zip.zip, and cannot find gh_2.20.2_windows_amd64.zip.ZIP, period.