Re: [PATCH v2 2/2] Handle more file writes correctly in shared repos

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 06, 2016 at 02:09:49PM +0100, Johannes Schindelin wrote:

> In shared repositories, we have to be careful when writing files whose
> permissions do not allow users other than the owner to write them.
> 
> In particular, we force the marks file of fast-export and the FETCH_HEAD
> when fetching to be rewritten from scratch.
> 
> This commit does not touch the following users of fopen() that want to
> write files:

The patch looks good, and thanks for cataloguing the other cases.

> - git am, when splitting mails (git-am correctly cleans up its directory
>   after finishing, so there is no need to share those files between users)
> 
> - git apply, when writing rejected hunks
> 
> - git fsck, when writing lost&found blobs

For these latter two, I had to ask myself "why not?". You gave such nice
reasons for the other items in the list, I wondered what your reasoning
was here. In the second case, for example, I think it would prevent a
second shared user from running `git fsck --lost-found`, because we are
likely to find the same "old" dangling objects and fail to write them.

I also wondered why we do not do the usual write-to-temp and rename in
some of these cases, but that is not really relevant to your patch.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]