Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gitea doctor will remove repo-avatar files #30037

Closed
eeyrjmr opened this issue Mar 24, 2024 · 4 comments · Fixed by #30094
Closed

gitea doctor will remove repo-avatar files #30037

eeyrjmr opened this issue Mar 24, 2024 · 4 comments · Fixed by #30094
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug
Milestone

Comments

@eeyrjmr
Copy link
Contributor

eeyrjmr commented Mar 24, 2024

Description

if a user configures a repo to have a custom avatar then gitea doctor check --fix --all deletes the associated avatar files.

STARTING CASE:
2024-03-24_00-03-1711240637
jupyterlab icon added to a repo

2024-03-24_00-03-1711240546
blob is found on the filesystem.

gitea doctor check --fix --all is executed and completes.

2024-03-24_00-03-1711240764
the repo-avatar directory is now empty.

viewing with a browser confirms the avatar is missing.
2024-03-24_00-03-1711240894
LEFT is chrome using cached image, RIGHT is incognito mode.

The behaviour of services/doctor/storage.go implies that orphaned files will be deleted
https://github.com/go-gitea/gitea/blob/e3e08dcc5184cdbdac5023fabaafba123a995c3e/services/doctor/storage.go#L92C1-L93C1

how to indicate that repo-avatars are not orphan files.

sidenote... what else could be classed as orphaned and incorrectly removed

Gitea Version

1.21.9

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

windows and linux

Database

MySQL/MariaDB

@yp05327 yp05327 added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label Mar 25, 2024
@yp05327
Copy link
Contributor

yp05327 commented Mar 26, 2024

Doctor handles the object id as storage path, but repo archiver needs relative path:
image
image
Then it will be detected as invalid storage path and will be deleted.
image
image

@lunny
Copy link
Member

lunny commented Mar 26, 2024

Doctor handles the object id as storage path, but repo archiver needs relative path: image image Then it will be detected as invalid storage path and will be deleted. image image

Can you send a PR to fix it?

@yp05327
Copy link
Contributor

yp05327 commented Mar 26, 2024

yeah, but it seems that the root reason is typo 😂
image

@yp05327
Copy link
Contributor

yp05327 commented Mar 26, 2024

By my test, if you reupload the same file, it will have no changes.
You need to reupload another one first, then reupload the original file.

@lunny lunny added this to the 1.21.11 milestone Mar 26, 2024
lunny pushed a commit that referenced this issue Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants