Re: git repack leaks disk space on ENOSPC

[Jeff King <peff@peff.net>]

On Thu, Oct 12, 2017 at 11:34:39AM +0200, Andreas Krey wrote:

> > Does using create_tempfile there seem like a good path forward to you?
> > Would you be interested in working on it (either writing a patch with
> > such a fix or a test in t/ to make sure it keeps working)?
> 
> I will look into creating a patch (thanks for the pointers),
> but I don't see how to make a testcase for this - pre-filling the
> disk doesn't sound like a good idea. Most people probably won't run in
> this situation, and then won't have tmp_packs with a dozen GBytes each
> lying around.

It may be easier to trigger a case which rejects the pack for other
reasons. For an incoming index-pack, turning on transfer.fsckObjects is
an easy one. For a repack, perhaps corrupting a loose object
to-be-packed would work.

E.g.:

  git init
  echo content >file
  git add file
  git commit -m foo

  # corrupt the blob in a subtle way
  obj=.git/objects/$(git rev-parse HEAD:file | sed 's,..,&/,')
  chmod +w $obj
  echo cruft >>$obj

After that, I get:

  $ git repack -ad
  Counting objects: 3, done.
  error: garbage at end of loose object 'd95f3ad14dee633a758d2e331151e950dd13e4ed'
  fatal: loose object d95f3ad14dee633a758d2e331151e950dd13e4ed (stored in .git/objects/d9/5f3ad14dee633a758d2e331151e950dd13e4ed) is corrupt

  $ find -type f .git/objects/pack
  .git/objects/pack/tmp_pack_0GaXwk

-Peff