Transfer the ownership 转移仓库所有权 do not work in V1.90~V1.92 #7947
Labels
No Label
backport/done
backport/v1.0
backport/v1.1
backport/v1.10
backport/v1.11
backport/v1.12
backport/v1.13
backport/v1.14
backport/v1.15
backport/v1.2
backport/v1.3
backport/v1.4
backport/v1.5
backport/v1.6
backport/v1.7
backport/v1.8
backport/v1.9
bounty
changelog
dependencies
frontport/done
frontport/main
good first issue
Hacktoberfest
hacktoberfest-accepted
in progress
kind/api
kind/breaking
kind/bug
kind/build
kind/deployment
kind/deprecated
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/misc
kind/moderation
kind/package
kind/proposal
kind/question
kind/refactor
kind/regression
kind/security
kind/summary
kind/testing
kind/translation
kind/ui
kind/upstream-related
kind/usability
kind/ux
lgtm/done
lgtm/need 1
lgtm/need 2
performance/bigrepo
performance/cpu
performance/memory
performance/speed
priority/critical
priority/low
priority/maybe
priority/medium
proposal/rejected
reviewed/confirmed
reviewed/duplicate
reviewed/fixed
reviewed/invalid
reviewed/not-a-bug
reviewed/wontfix
skip-changelog
stale
status/blocked
status/needs-feedback
status/wip
theme/2fa
theme/authentication
theme/avatar
theme/backup-restore
theme/docker
theme/federation
theme/issues
theme/kanban
theme/markdown
theme/migration
theme/mobile
theme/pr
theme/signing
theme/sqlite
theme/timetracker
theme/webhook
theme/wiki
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: lunny/gitea#7947
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
i loopback to v1.83,it works.
(Please forgive if I read 转移仓库所有权 incorrectly. I am using Gitea with English language settings)
Do you get a specific error why trying to use "Transfer Ownership" from the repository settings?
I just tested in https://try.gitea.io/demoorg1/iss7947 (which is actually v1.10.0 dev build), and was able to transfer this repo from myself, to be owned by a different organization.
In my personal Gitea instance running v1.9.2 I was also able to Transfer Ownership of a repository to a different username.
In the gitea.log, I think it looks something like this:
I didn't encounter a problem when testing it. Hopefully your log may show some interesting messages
log on console:
logfile:
the login ID is admin ,has the rights of all the repo,why Access is denied.
system: win2008 R2
git version 2.22.0.windows.1
gitea:1.92
Maybe you should not store you gitea data on C:\ on windows since it's a system disk
@lunny I'm experiencing frequent 500 errors after transferring repos to an organization.
This is recent as I upgraded to Gitea
1.9.2
just last week and coincides with the 500s.I'm currently resolving this by
stop
ing and restart
ing my gitea service installd on Raspbian (raspberry pi, arm7).@loup-brun A "500 error" is a generic code meaning "something unexpected happened". It would be very useful if you could paste here a relevant part of your gitea.log from the moment the error happened.
Here is a log right after getting my 500 errors:
Seems like you are running out of memory
@lafriks any suggestion on how to resolve this? That's what I thought, so I searched the Gitea documentation for options to configure memory limit on my gitea installation, but I found no option.
I am experiencing this only on repos recently transferred to an organization (old repos are fine).
@loup-brun Perhaps those repos have other issues besides having been recently transferred. Are they big? Have many files? Many commits? You could try running some git commands on them yourself directly from the shell and see what happens. For instance, there is git-fsck that does some sanity checks. Gitea can do git-fsck itself, but if you doubt Gitea it could be nice to have a "second opinion" directly from git.
Also, make sure to use the same user as Gitea for those tests. The root user, for instance, will not have the same restrictions in resource usage.
@guillep2k Small repos (max 4 MB), few files, max 10 commits. Only new projects (created since I updated to Gitea
1.9.2
from1.8
), which is why I suspect it has something to do with the update.(old repos created before the update not affected by this bug)
@loup-brun It wouldn't hurt checking them anyway. Could they have become corrupted somehow?
If you are interested, the standard procedure in my company is for the dev to create the repository, have some structural work done and then transfer it to the company org. We are using 1.9.2 without problems so far.
@loup-brun what's your git version and how did you install it?
@guillep2k I run git fsck without any problem (and have this feature turned on in Gitea).
@lunny I have
git version 2.11.0
installed.I simply update my gitea by replacing the binary
/usr/local/bin/gitea
(with appropriate group/file permissions) andrestart
ing the gitea service.I rolled back to gitea
1.8.3
(just like @gwnpeter) which works fine, no error whatsoever on those repos which I transferred ownership (tested them all several times a day for 2-3 days now).On Windows, seems that some file still locked during os.Rename
The file object\XXXXXXXXXXXXXXXXXXXXXX.pack still locked
This looks like a concurrency problem, and IMHO difficult to solve in a bulletproof way. You have more than one process accessing the repo at the time of migration, so the migration code fails.
If you think your users are not accessing it, please check whether any automated tool either is running things on it or left processes behind locking the file. In Windows I've found that Process Explorer (a Microsoft official utility) has a search handle function that tells you which processes have a particular file open. It may be of help.
Another related and very useful utility (you can check that out) is Process Monitor, although it's a bit more difficult to use. You need to set up the filters to log only the pahts you're interested in.
I've tried with Process Monitor, pack file is locked by gitea.exe. I've put a 30sec pause before the rename, close the locked file with Process Monitor and after the pause, the repository is transfered right
I think that some git operation was transferred from
git
to a go library (go-git
?) in 1.9.0. Perhaps that library does some caching or needs some garbage collection in order to free the files?@nikybiasion Please try the following: remove the delay from the code, but wait in the UI 30 seconds before pressing the last confirmation button. If the problem goes away, it means that the lock is produced in some operation from the page rendered before.
Another interesting test is placing the 30s delay in different parts of the code, from the earliest point to the latest (you know that one works), until we find the point that is introducing the lock. BTW good catch!
if i go to transfer page, wait until the lock disapper, click transfer, i get 500 error and the pack file became locked.
Good to know; if you can confirm that no other accesses were being made to that repo, that should tell us that Gitea is locking itself withing the transfer procedure. That certainly shortens the search.