Corrupted download archives #5383

New Issue

GiteaMirror · 2025-11-02T06:23:07-06:00

GiteaMirror commented

2025-11-02 06:23:07 -06:00

Originally created by @japettyjohn on GitHub (May 11, 2020).

Gitea version (or commit ref): 1.11.3
Git version: 2.11.0
Operating system: 9.12
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

The API to download a zip/tgz archive does not cleanup the archive made in the case of an error. So while a 500 will result from the first attempt, all subsequent attempts on the same commit ID will get the corrupted file from the disk and a 200 OK. This is not addressed in master (b7c82cd1a9) either.

Reproducing this is a requires making the git archive command fail. In my case this was from a timeout.

Screenshots

No UI elements involved.

Originally created by @japettyjohn on GitHub (May 11, 2020). - Gitea version (or commit ref): 1.11.3 - Git version: 2.11.0 - Operating system: 9.12 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description The API to download a zip/tgz archive does not cleanup the archive made in the case of an error. So while a 500 will result from the first attempt, all subsequent attempts on the same commit ID will get the corrupted file from the disk and a 200 OK. This is not addressed in [master (b7c82cd1a9)](https://github.com/go-gitea/gitea/blob/b7c82cd1a9ce4f863034a3a59312ff9402a8f72c/modules/git/commit_archive.go#L61) either. Reproducing this is a requires making the `git archive` command fail. In my case this was from a timeout. ## Screenshots No UI elements involved.

GiteaMirror added the issue/confirmed type/bug labels 2025-11-02 06:23:07 -06:00

GiteaMirror closed this issue

2025-11-02 06:23:08 -06:00

GiteaMirror commented

2025-11-02 06:23:08 -06:00

@kevans91 commented on GitHub (May 12, 2020):

This can or will be alleviated by #11296, perhaps, which starts generating the archives off in tmpdir then quickly copying them over to their final location upon success.

@kevans91 commented on GitHub (May 12, 2020): This can or will be alleviated by #11296, perhaps, which starts generating the archives off in tmpdir then quickly copying them over to their final location upon success.

GiteaMirror commented

2025-11-02 06:23:08 -06:00

@heindl-solutions commented on GitHub (May 13, 2020):

timeout settings added in #6015 might help

@heindl-solutions commented on GitHub (May 13, 2020): timeout settings added in #6015 might help

GiteaMirror commented

2025-11-02 06:23:09 -06:00

@stale[bot] commented on GitHub (Jul 12, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Jul 12, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

2025-11-02 06:23:09 -06:00

@OzWookiee commented on GitHub (May 15, 2021):

Can confirm I have this issue with the latest version of Gitea. We have a large repo but have limited the archive to a single directory with .gitattributes however the release archive creates a broken zip/tar of 580Mb when it should be around 1.7Gb

[git.timeout]
DEFAUlT = 720
MIGRATE = 1200
MIRROR = 600
CLONE = 600
PULL = 600
GC = 120

these changes to the app.ini have not had an impact on the archive creation.

@OzWookiee commented on GitHub (May 15, 2021): Can confirm I have this issue with the latest version of Gitea. We have a large repo but have limited the archive to a single directory with .gitattributes however the release archive creates a broken zip/tar of 580Mb when it should be around 1.7Gb ``` [git.timeout] DEFAUlT = 720 MIGRATE = 1200 MIRROR = 600 CLONE = 600 PULL = 600 GC = 120 ``` these changes to the app.ini have not had an impact on the archive creation.

GiteaMirror commented

2025-11-02 06:23:09 -06:00

@zeripath commented on GitHub (May 15, 2021):

Please don't comment on closed issues - open a new one referring to the closed issue so that we get full information.

Gitea generates >100 notifications a day - commenting on closed issues is a good way to get ignored.

@zeripath commented on GitHub (May 15, 2021): Please don't comment on closed issues - open a new one referring to the closed issue so that we get full information. Gitea generates >100 notifications a day - commenting on closed issues is a good way to get ignored.

GiteaMirror referenced this issue

2025-11-02 15:41:26 -06:00

[PR #5383] [MERGED] API: '/orgs/:org/repos': return private repos with read access #17775

GiteaMirror referenced this issue

2025-11-02 15:44:19 -06:00

[PR #5393] [MERGED] API: '/orgs/:org/repos': return private repos with read access #17780

Sign in to join this conversation.