From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Ephrim Khong <dr.khong@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [RFC PATCH] merge-recursive: create new files with O_EXCL
Date: Sat, 13 Mar 2021 01:08:11 +0000 [thread overview]
Message-ID: <YEwQe0qMUtlI5PCl@camp.crustytoothpaste.net> (raw)
In-Reply-To: <cd7c6682-7409-f72c-8751-02b70a423f83@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
prev parent reply other threads:[~2021-03-13 1:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 7:57 [RFC PATCH] merge-recursive: create new files with O_EXCL Ephrim Khong
2021-03-10 23:01 ` Junio C Hamano
2021-03-11 9:54 ` Ephrim Khong
2021-03-11 17:52 ` Junio C Hamano
2021-03-11 18:01 ` Elijah Newren
2021-03-13 1:08 ` brian m. carlson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YEwQe0qMUtlI5PCl@camp.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=dr.khong@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).