Re: [PATCH v3 0/2] Correctly handle transient files in shared repositories

On Mon, Jan 11, 2016 at 01:22:07PM -0800, Junio C Hamano wrote:

     - git fsck, when writing lost&found blobs (they are written in the
       file under its object name, so an existing file with tighter
       permission that you cannot write into is OK, because what you are
       failing to write is the same contents that the file already has
       anyway).

I'm not sure I buy this argument. Yes, you should not be writing
anything else, but that does not change the fact that "fsck" will
unceremoniously abort:

  $ git init
  $ echo foo | git hash-object -w --stdin
  $ git fsck --lost-found
  notice: HEAD points to an unborn branch (master)
  Checking object directories: 100% (256/256), done.
  notice: No default references
  dangling blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99

  $ chmod -w .git/lost-found/other/257cc5642cb1a054f08cc83f2d943e56fd3ebe99 
  $ $ git fsck --lost-found
  notice: HEAD points to an unborn branch (master)
  Checking object directories: 100% (256/256), done.
  notice: No default references
  dangling blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99
  fatal: Could not open '.git/lost-found/other/257cc5642cb1a054f08cc83f2d943e56fd3ebe99': Permission denied

So I think this would be a reasonable candidate (or alternatively, to
treat EPERM on an existing file as a soft error). I am totally fine not
to address it as part of this series, though.

-Peff