neuropoly/gitea

Deleting repos with locked annex content

kousu opened this issue · 5 comments

kousu commented

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:

recreate

files

delete

deleted

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 commented

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

    Screenshot 2022-05-15 at 11-09-10 public2

    [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 #1 (comment)

kousu commented

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

kousu commented

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.