On 2021-03-11 at 09:54:41, Ephrim Khong wrote:
> On 11.03.2021 00:01, Junio C Hamano wrote:
> >  * understand why your NFS mount is broken and give a better
> >    explanation as to why we need to have a workaround in our code.
> 
> I'll work on this, but unfortunately have no idea of how to properly
> debug it. Since it is a company server without administrative rights and
> the backend is some IBM storage system, the options are limited and
> processes are slow. What I did find out so far is that it is not a race
> condition with unlink. A simple openat() without O_EXCL already produces
> the wrong file mode.

This reminds me of a NFS bug that we saw in the past[0].  I don't know
if you're using that same type of system in this case, but if so, it
could be part of the problem.

Since buggy NFS implementations seem to be a problem specifically with
open(2) and I need to reroll my series to add some entries to the FAQ,
and I'll document that we require NFS servers to support POSIX open
semantics, including permissions and O_EXCL.

> (I fully understand that this is not a bug on git's side, and I found no
> documentation indicating that O_EXCL would be recommended or have any
> effect in this way. Hopefully, others that run into similar issues would
> benefit from this as well, there are a few reports online of people
> running into "failed to refresh" errors.)

This does tend to frequently affect Git, but it can also affect other
programs as well, and you're probably going to be better off filing a
bug report with IBM about their NFS server than trying to work around it
in every situation.

[0] https://lore.kernel.org/git/CAPx1GvfKxu8gwbp0Gn2dBf9th874skKjD-echeAFr7_77o8FYw@mail.gmail.com/T/#mead6be6c92f0ab29cf9fd600781dea7315e87411
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US