On 18 November 2014 08:34, Jeff King <peff@xxxxxxxx> wrote: >> >> 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? -- 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