You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When in a Gitea repo, one may go to “Settings→LFS→Find pointer files” to see a list/table of LFS blob pointers about which Gitea knows something. The last three columns in that table are labelled “In Repo”, “Exists in Store” and “Accessible to User”. If documentation on their meaning exists, I have not found it, but I'm assuming the following:
In Repo: Is referenced by some commit in some branch of the repository
Exists in Store: Is present in the LFS store of Gitea, i.e. could be downloaded from the server when checking out the repo
Accessible to User: [actually, I have no idea]
I can however reliably create a situation where a file is present in the store and marked as “In Repo” that is not referenced in any commit present in the repo. (And we have at least one actual repository where that happened to one of our users naturally.) These files seem to be unnoticed by both the health check as well as the garbage collector.
When clicking “Find commits” there are “No Commits found for this LFS file”. When going through the revision of the repo with git ls-tree, the id of the LFS pointer file is not found (hence my claim that these are not present even in repos to large to check by hand).
How to reproduce
I have tested this while running a Linux with Bash on my client but I would assume that this takes only minimal or no changes to be run on other clients.
Create a new repo in Gitea and make note of the remote access url, e.g. ssh://git@gitea.example.org:22/User/repo.git
Make this script executable in some file, e.g. ./lfs-confusion.sh
Execute the script with the url as argument, e.g. $ ./lfs-confusion.sh ssh://git@gitea.example.org:22/User/repo.git
The result should be a repo which has only a single branch and only a single commit on that branch and only a single file in that commit where the file is not stored via LFS but under the LFS settings a file is listed as being “In Repo” (as well as “Exists in Store” and “Accessible to User”).
Description
When in a Gitea repo, one may go to “Settings→LFS→Find pointer files” to see a list/table of LFS blob pointers about which Gitea knows something. The last three columns in that table are labelled “In Repo”, “Exists in Store” and “Accessible to User”. If documentation on their meaning exists, I have not found it, but I'm assuming the following:
I can however reliably create a situation where a file is present in the store and marked as “In Repo” that is not referenced in any commit present in the repo. (And we have at least one actual repository where that happened to one of our users naturally.) These files seem to be unnoticed by both the health check as well as the garbage collector.
When clicking “Find commits” there are “No Commits found for this LFS file”. When going through the revision of the repo with
git ls-tree
, the id of the LFS pointer file is not found (hence my claim that these are not present even in repos to large to check by hand).How to reproduce
I have tested this while running a Linux with Bash on my client but I would assume that this takes only minimal or no changes to be run on other clients.
ssh://git@gitea.example.org:22/User/repo.git
./lfs-confusion.sh
$ ./lfs-confusion.sh ssh://git@gitea.example.org:22/User/repo.git
The result should be a repo which has only a single branch and only a single commit on that branch and only a single file in that commit where the file is not stored via LFS but under the LFS settings a file is listed as being “In Repo” (as well as “Exists in Store” and “Accessible to User”).
Gitea Version
1.16.9
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
https://gist.github.com/HermannDppes/b3068c952aedb5210fdd6d6d8172cf88 (More extensive log to follow as soon as I find the time and patience to clean up the data I might not want to leak.)
Screenshots
Git Version
2.30.2
Operating System
Debian 10 (Buster)
How are you running Gitea?
From downloaded binary, started via systemd
Database
MySQL
Edits
Added
in the second paragraph, as this somehow slipped by and is a rather important restriction.
The text was updated successfully, but these errors were encountered: