git lfs pushed files are empty #5024

New Issue

GiteaMirror · 2025-11-02T06:11:31-06:00

GiteaMirror commented

2025-11-02 06:11:31 -06:00

Originally created by @markus-seidl on GitHub (Mar 8, 2020).

Gitea version (or commit ref): 1.11.2
Git version: 2.17.1; git-lfs 2.3.4
Operating system: Ubuntu 18.04
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant; LFS not enabled on try.gitea.io !
Log gist: https://gist.github.com/markus-seidl/c9f51da5e5855d811581970517e0b339

Description

I try to push files from a client repository that has LFS enabled. LFS is enabled on the server and the push succeeds. Also the settings page of the repository lists the files as stored in the repository with their correct sizes.
However, on the next

clone
Zip download of the repository
Or direct download via web ui
the files are empty or result in a 500 error. The 500 is, because the files are not there.

Screenshots

Originally created by @markus-seidl on GitHub (Mar 8, 2020).   - Gitea version (or commit ref): 1.11.2 - Git version: 2.17.1; git-lfs 2.3.4 - Operating system: Ubuntu 18.04 - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant; LFS not enabled on try.gitea.io ! - Log gist: https://gist.github.com/markus-seidl/c9f51da5e5855d811581970517e0b339 ## Description I try to push files from a client repository that has LFS enabled. LFS is enabled on the server and the push succeeds. Also the settings page of the repository lists the files as stored in the repository with their correct sizes. However, on the next * clone * Zip download of the repository * Or direct download via web ui the files are empty or result in a 500 error. The 500 is, because the files are not there. ## Screenshots

GiteaMirror closed this issue

2025-11-02 06:11:31 -06:00

GiteaMirror commented

2025-11-02 06:11:32 -06:00

@markus-seidl commented on GitHub (Mar 8, 2020):

The solution is: The server didn't have access to the lfs directory and was swallowing the exception / warning / error.

I would suggest the exception about not being able to access the lfs directory should show up somewhere :)

@markus-seidl commented on GitHub (Mar 8, 2020): The solution is: The server didn't have access to the lfs directory and was swallowing the exception / warning / error. I would suggest the exception about not being able to access the lfs directory should show up somewhere :)

GiteaMirror commented

2025-11-02 06:11:32 -06:00

@zeripath commented on GitHub (Mar 8, 2020):

I was about to say that your logs looked a bit sparse...

Looking at the code error should have been passed to the client at least - which is also incorrect because these errors might need sanitising.

Sigh I guess I'll have to go through and add logging to this.

@zeripath commented on GitHub (Mar 8, 2020): I was about to say that your logs looked a bit sparse... Looking at the code error should have been passed to the client at least - which is also incorrect because these errors might need sanitising. *Sigh* I guess I'll have to go through and add logging to this.

GiteaMirror commented

2025-11-02 06:11:32 -06:00

@zeripath commented on GitHub (Mar 8, 2020):

Oh yeah I remember git-lfs may keep hitting the server if it gets a 500! So returning 500 for a permanent error will cause badness.

@zeripath commented on GitHub (Mar 8, 2020): Oh yeah I remember git-lfs may keep hitting the server if it gets a 500! So returning 500 for a permanent error will cause badness.

GiteaMirror commented

2025-11-02 06:11:33 -06:00

@markus-seidl commented on GitHub (Mar 10, 2020):

Thank you very much! @zeripath

@markus-seidl commented on GitHub (Mar 10, 2020): Thank you very much! @zeripath

GiteaMirror referenced this issue

2025-11-02 14:20:23 -06:00

[PR #5024] [MERGED] Explicitly decide whether to use TLS in mailer's configuration #17598

Sign in to join this conversation.