Re: [PATCH] gc: support temporarily preserving garbage
- From
- Stefan Saasen <ssaasen@atlassian.com>
- Date
- Nov 17, 2014, 23:59 UTC
- Message-ID
- <CADoxLGMFzujP6kKNpExsCSzQrUrpsgPOcgLmFA_yU7S=NhQorQ@mail.gmail.com>
- In-Reply-To
- <20141117213442.GD15880@peff.net>
On 18 November 2014 08:34, Jeff King <peff@peff.net> wrote:
Show 12 quoted lines
>> >> I am not sure if this much of code churn is warranted to work around >> issues that only happen on repositories on NFS servers that do not >> keep open-but-deleted files available. Is it an option to instead >> have a copy of repository locally off NFS? > > I think it is also not sufficient. This patch seems to cover only > objects. But we assume that we can atomically rename() new versions of > files into place whenever we like without disrupting existing readers. > This is the case for ref updates (and packed-refs), as well as the index > file. The destination end of the rename is an unlink() in disguise, and > would be susceptible to the same problems.
I’m going out on a limb here as my NFS knowledge is rather shallow but a rename should be atomic even on NFS.
"The RENAME operation must be atomic to the client.” (https://www.ietf.org/rfc/rfc1813.txt: 3.3.14)
Does git do something differently here for that not to be the case?