git repack -ad can damage a repository that’s partially unreadable by the current user

[Removed by request]

I'm using Ubuntu 14.10 dev with git 1:2.0.1-1 and if git-gc hasn't full write-access to a repository it can damage it. Getting such a permission state for a git repository isn't even unlikely if it was optimized in a sudo environment before. Here is an example output:

sworddragon@ubuntu:~/.git/tvoip$ sudo git gc --aggressive --prune=now
Counting objects: 1250, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (1220/1220), done.
Writing objects: 100% (1250/1250), done.
Total 1250 (delta 944), reused 295 (delta 0)
sworddragon@ubuntu:~/.git/tvoip$ git gc --aggressive --prune=now
fatal: internal error: packed-ref cache cleared while locked
error: failed to run pack-refs

[Anders Kaseorg (andersk)]

I cannot reproduce. The pack files generated by ‘sudo git gc’ are owned by root, but Git never writes to pack files except when initially creating them, so this doesn’t cause any problems.

How do you know that your repository was damaged? Can you give instructions to reproduce the problem from scratch?

[Removed by request (removed3425744)]

> How do you know that your repository was damaged?

> Can you give instructions to reproduce the problem from scratch?

I wanted now to make a testcase but while doing so I have noticed that the repository doesn't got damaged but I got still errors (like seeing no commits anymore) because the permissions were still missing. My user uses a default umask of 077 which is propably causing this behavior if combined with sudo.

[Anders Kaseorg (andersk)]

Okay. Do you still think this is a bug? Given what happened, I’m having trouble imagining how one could expect Git to do anything else.

[Removed by request (removed3425744)]

> Okay. Do you still think this is a bug?

On testing it a little more I have figured out that I have made an error on creating the testcase that let me think that the repository doesn't get damaged. Here is now a testcase that natively damages a repository:

1. Make sure your user has an umask of 077 (for example by replacing #022 with 077 in ~/.profile and probably by loging out and in again).
2. Download a repository (for example I'm testing with "git clone git://git.code.sf.net/p/tvoip/code tvoip").
3. Go into the directory of the repository.
3. Call "git log" to validate that the repository is currently undamaged.
4. Instead of calling git-gc the repository gets now optimized more manually with 'sudo bash -c "git pack-refs --all; git reflog expire --all --expire-unreachable=now --expire=now; git repack --depth 250 --window 250 -Fad; git rerere gc; git prune --expire now"'.
5. Call the same command without sudo (an error should appear).
6. Call "sudo git log" to see that no commits are available anymore.

[Anders Kaseorg (andersk)]

I can confirm using that test case. It looks like the step that causes damage is ‘git repack -ad’.

Would you be willing to report this to the upstream Git mailing list?

[Removed by request (removed3425744)]

> Would you be willing to report this to the upstream Git mailing list?

If the mailing list is vger.kernel.org this is propably not possible because my mails are always marked as spam (https://bugzilla.kernel.org/show_bug.cgi?id=70591).

[Removed by request (removed3425744)]

On retesting this with git 1:2.8.1-1 and the reproduction steps from comment #5 I'm still getting an error after step 5 but after step 6 the commits are still there. But now I'm wondering if really nothing got damaged. Can somebody confirm this?