Deleting repos with locked annex content

[kousu]

A bug:

When deleting a repo, Gitea can't delete annex/objects files (because of this known problem), so you cannot reuse the name if there were ever an annex stored in it:

   But the annex files are still there: ``` [kousu@nigiri gitea]$ tree data/gitea-repositories/kousu/public1.git/ data/gitea-repositories/kousu/public1.git/ └── annex └── objects └── 359 └── 272 └── SHA256E-s16777216--d99c7957d3bb557079be12a72180f1c51460d3b6bdbcb762e5754dcaf2863cf3.bin └── SHA256E-s16777216--d99c7957d3bb557079be12a72180f1c51460d3b6bdbcb762e5754dcaf2863cf3.bin 5 directories, 1 file ```

[kousu]

Possible solutions:

1. Figure out how to disable git-annex's write protection -- it should be unnecessary on a bare repo locked behind Gitea

   • There's two settings: annex.freezecontent-command, annex.thawcontent-command that you can find in man git-annex or here which are additional scripts that run after the internal write protection. Using them, I managed to circumvent the write protection:

     1. Create a repo kousu/public2
     2. Run git --git-dir data/gitea-repositories/kousu/public2.git/ config annex.freezecontent-command "chmod -R +w %path"
     3. Create an annexed repo and git annex sync --content to this repo

     Then the write bit is set:

     [kousu@nigiri gitea]$ ls -l data/gitea-repositories/kousu/public2.git/annex/objects/7c8/5fe/SHA256E-s16777216--2412b6fae9e6b034da16d429373b988dfc101f99d1d890286c0e46f077018974.bin/
     total 16384
     -rw-r--r-- 1 kousu kousu 16777216 May 15 11:08 SHA256E-s16777216--2412b6fae9e6b034da16d429373b988dfc101f99d1d890286c0e46f077018974.bin

     And after deleting

     

     [kousu@nigiri gitea]$ ls -l data/gitea-repositories/kousu/public2.git/
     ls: cannot access 'data/gitea-repositories/kousu/public2.git/': No such file or directory

     It would be nicer if there was a way to set this globally and automatically.

     EDIT: I think the best workaround is

     git config --global annex.freezecontent-command 'sh -c '"'"'[ "$(git config core.bare)" = "true" ] && chmod -R +w %path'"'"

     but this needs git-annex >= 10

2. Add chmod -R +w annex/objects into the Delete A Repo subroutine

   According to git-annex's docs this is their preferred solution. But they are thinking you're doing all this manually; that would be difficult to do correctly in an automated way.

Originally posted by @kousu in https://github.com/neuropoly/gitea/issues/1#issuecomment-1126956372

[kousu]

I've posted about this with git-annex, but I don't think we should wait for their advice.

[kousu]

joeyh got back to us:

I agree it would be better if gitolite could be modified to only set the write bits before deleting the repository. It seems to me that gitolite demonstratably has a bug, because you show it fail to delete everything but apparently behave as if it succeeded. Perhaps setting the write bits could be justified to the gitolite developers as a way to make it more robust when removing a repository, in case some permission problem prevents deleting the content of a directory.

So he doesn't want to fix it in git-annex, and wants us to solve it with solution 2. Too bad.

[kousu]

Solved (with option 2) here:

https://github.com/neuropoly/gitea/blob/c307a30201740c4d0c8c4e1f10e8ca2ad52a74d2/modules/util/remove.go#L48-L72

[kousu]

Also tested here, so we can be confident:

https://github.com/neuropoly/gitea/blob/c307a30201740c4d0c8c4e1f10e8ca2ad52a74d2/tests/integration/git_annex_test.go#L387-L394