gitea doctor consistently reports orphaned LFS #14311

New Issue

GiteaMirror · 2025-11-02T11:09:31-06:00

GiteaMirror commented

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

Originally created by @eeyrjmr on GitHub (Mar 27, 2025).

Description

Recently LFS has started to be used to manage binary data.
Gitea doctor check --fix --all removed all LFS files. These were restored from backup. Closer inspection of gitea doctor is showing that all LFS data is orphaned

However, the equivalent view from the repo in question appears to indicate all is ok

All clones and interactions are consistent but the check appears to be incorrectly flagging an issue.

Gitea Version

1.23.6

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.49.0

Operating System

Windows

How are you running Gitea?

Windows service

Database

SQLite

Originally created by @eeyrjmr on GitHub (Mar 27, 2025). ### Description Recently LFS has started to be used to manage binary data. **Gitea doctor check --fix --all** removed all LFS files. These were restored from backup. Closer inspection of gitea doctor is showing that all LFS data is orphaned ![Image](https://github.com/user-attachments/assets/d1e3a3e1-80a8-4321-b0f4-0311e5881093) However, the equivalent view from the repo in question appears to indicate all is ok ![Image](https://github.com/user-attachments/assets/5fd4b262-f81c-46ae-950d-6ef7b0ed7ae9) All clones and interactions are consistent but the check appears to be incorrectly flagging an issue. ### Gitea Version 1.23.6 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.49.0 ### Operating System Windows ### How are you running Gitea? Windows service ### Database SQLite

GiteaMirror added the type/bug label 2025-11-02 11:09:31 -06:00

GiteaMirror closed this issue

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

GiteaMirror commented

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

@eeyrjmr commented on GitHub (Mar 27, 2025):

I am trying to understand what passes as an LFS orphan and I wonder if it is also associated with: https://github.com/go-gitea/gitea/pull/34035

@eeyrjmr commented on GitHub (Mar 27, 2025): I am trying to understand what passes as an LFS orphan and I wonder if it is also associated with: https://github.com/go-gitea/gitea/pull/34035

GiteaMirror commented

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

@eeyrjmr commented on GitHub (Mar 28, 2025):

This might be a windows subtly but how LFS is done on windows (be it gitea or git-lfs) means the hash filename is actually packed into the directory

Looking in the BARE repositories the gitea-repositories/$ORG/$REPO.git/lfs/objects/ae/b3/ is empty but that makes sense if gitea then manages the RAW data, via pointers, thus the total hash vs dir/dir/partial_hash might be the issue because if gitea doctor was trying to find the file lfs/ae/b3/aeb4d3fbb... but is finding lfs/ae/b3/d3fbb... it would explain why doctor says all is orphan

https://github.com/git-lfs/git-lfs/wiki/Tutorial

I need to test on a linux machine but the git-lfs documentation implies the full filename aligns with the hash/point and not split across the directories.

@eeyrjmr commented on GitHub (Mar 28, 2025): This might be a windows subtly but how LFS is done on windows (be it gitea or git-lfs) means the hash filename is actually packed into the directory ![Image](https://github.com/user-attachments/assets/0c803151-f6f9-4a03-aef3-3f70435b2a4b) ![Image](https://github.com/user-attachments/assets/5a951251-72e8-423a-9e20-1eeb39c816f1) Looking in the BARE repositories the gitea-repositories/$ORG/$REPO.git/lfs/objects/ae/b3/ is empty but that makes sense if gitea then manages the RAW data, via pointers, thus the total hash vs dir/dir/partial_hash might be the issue because if gitea doctor was trying to find the file lfs/ae/b3/aeb4d3fbb... but is finding lfs/ae/b3/d3fbb... it would explain why doctor says all is orphan https://github.com/git-lfs/git-lfs/wiki/Tutorial ![Image](https://github.com/user-attachments/assets/381849c8-2f40-46a7-84e1-a975b5a2bdca) I need to test on a linux machine but the git-lfs documentation implies the full filename aligns with the hash/point and not split across the directories.

GiteaMirror commented

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

@wxiaoguang commented on GitHub (Mar 28, 2025):

thus the total hash vs dir/dir/partial_hash might be the issue because if gitea doctor was trying to find the file lfs/ae/b3/aeb4d3fbb... but is finding lfs/ae/b3/d3fbb..

It seems to be a serious bug if so .....

@wxiaoguang commented on GitHub (Mar 28, 2025): > thus the total hash vs dir/dir/partial_hash might be the issue because if gitea doctor was trying to find the file lfs/ae/b3/aeb4d3fbb... but is finding lfs/ae/b3/d3fbb.. It seems to be a serious bug if so .....

GiteaMirror commented

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

@eeyrjmr commented on GitHub (Mar 28, 2025):

I think this is a gitea issue :(
https://github.com/git-lfs/git-lfs/issues/5845 and this is a git-lfs closed issue showing the directory structure is as expected. At least gitea can serve the lfs files just the doctor is expecting consistency :(

I will cross-check on linux later while try to figure out how gitea and doctor works out the pointers for lfs.

I have also tried gogit and nogogit for windows as I saw there are specific functions in gitea for gogit and nogogit. Same issue. I will however make a test repo to see if the gogit then makes a valid structure

@eeyrjmr commented on GitHub (Mar 28, 2025): I think this is a gitea issue :( https://github.com/git-lfs/git-lfs/issues/5845 and this is a git-lfs closed issue showing the directory structure is as expected. At least gitea can serve the lfs files just the doctor is expecting consistency :( I will cross-check on linux later while try to figure out how gitea and doctor works out the pointers for lfs. I have also tried gogit and nogogit for windows as I saw there are specific functions in gitea for gogit and nogogit. Same issue. I will however make a test repo to see if the gogit then makes a valid structure

GiteaMirror commented

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

@eeyrjmr commented on GitHub (Mar 28, 2025):

checked on linux... the structure is the same as windows in that the directory name is part of the overall pointer (separate discussion) but the gitea doctor check --run storages is showing all is ok

so this would appear to be windows specific and how gitea doctor determines orphens

@eeyrjmr commented on GitHub (Mar 28, 2025): checked on linux... the structure is the same as windows in that the directory name is part of the overall pointer (separate discussion) but the gitea doctor check --run storages is showing all is ok so this would appear to be windows specific and how gitea doctor determines orphens

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14311