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

From: Jeff King <peff@peff.net>
Date: Jan 11, 2016, 21:38 UTC
Message-ID: <20160111213801.GB21131@sigill.intra.peff.net>
In-Reply-To: <xmqq60yzx14w.fsf@gitster.mtv.corp.google.com>

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

Show 5 quoted lines

>      - 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