From: Jessica Clarke <jrtc27@jrtc27.com>
To: Brandon Casey <drafnel@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>, git <git@vger.kernel.org>,
Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] config.mak.uname: Define FREAD_READS_DIRECTORIES for GNU/Hurd
Date: Wed, 22 Apr 2020 19:50:44 +0100 [thread overview]
Message-ID: <452EC7D1-BE96-4172-8F70-3E7384C87280@jrtc27.com> (raw)
In-Reply-To: <CA+sFfMfre6W5GcPh1pWcroFD9S9OPj_uLp5CK11yh-UhqgDs2w@mail.gmail.com>
On 22 Apr 2020, at 19:48, Brandon Casey <drafnel@gmail.com> wrote:
> On Wed, Apr 22, 2020 at 9:41 AM Jonathan Nieder <jrnieder@gmail.com> wrote:
>>
>> Jessica Clarke wrote:
>>
>>> GNU/Hurd is another platform that behaves like this. Set it to
>>> UnfortunatelyYes so that config directory files are correctly processed.
>>> This fixes the corresponding 'proper error on directory "files"' test in
>>> t1308-config-set.sh.
>>>
>>> Thanks-to: Jeff King <peff@peff.net>
>>> Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
>>> ---
>>> config.mak.uname | 1 +
>>> 1 file changed, 1 insertion(+)
>>
>> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>> Thanks.
>>
>>> diff --git a/config.mak.uname b/config.mak.uname
>>> index 0ab8e00938..3e526f6b9f 100644
>>> --- a/config.mak.uname
>>> +++ b/config.mak.uname
>>> @@ -308,6 +308,7 @@ ifeq ($(uname_S),GNU)
>>> NO_STRLCPY = YesPlease
>>> HAVE_PATHS_H = YesPlease
>>> LIBC_CONTAINS_LIBINTL = YesPlease
>>> + FREAD_READS_DIRECTORIES = UnfortunatelyYes
>>> endif
>>
>> I wonder why we set up this knob this way. A lot of operating systems
>> support fopen(..., "r") of a directory --- wouldn't it make sense for
>> FREAD_READS_DIRECTORIES to be the default and for users on stricter
>> platforms to be able to set FREAD_DOES_NOT_READ_DIRECTORIES if they
>> want to speed Git up by taking advantage of their saner fread?
>
> At the time it was written, the assumption in the code was that an
> fread() on a directory would produce a failure, and that that was the
> sane and common behavior. fopen(..., "r") on a directory was expected
> to be successful on most platforms, but does fail on some. I don't
> recall if it failed on any of the platforms I had access to at the
> time (Solaris, IRIX), but it does fail on Windows. So I introduced
> this feature that would make fopen() fail when opening a directory for
> use on the platforms where fread() of a directory did not fail,
> instead of trying to wrap fread().
>
> I just looked in config.mak.uname, and I'm surprised to see
> FREAD_READS_DIRECTORIES set for so many platforms. And it's set for
> Linux and Darwin?!?!? Junio added it for Darwin
> (8e178ec4d072da4cd8f4449e17aef3aff5b57f6a) and Nguyễn Thái Ngọc Duy
> added it for Linux (e2d90fd1c33ae57e4a6da5729ae53876107b3463), but
> also seemed to mistake the intention of FREAD_FREADS_DIRECTORIES as
> being about the fopen(..., "r") of a directory rather than about an
> fread() of a directory.
>
> I just wrote a test program and tested on Linux, Darwin, and Windows.
> Linux and Darwin both succeed to fopen() a directory and fail to
> fread() it, as expected. Windows fails to fopen() a directory.
>
> I notice this earlier commit mentions a failure of t1308
> (4e3ecbd43958b1400d6cb85fe5529beda1630e3a). I wonder if this is the
> reason FREAD_READS_DIRECTORIES was added to so many platforms?
Then the current autoconf test is wrong and likely causing confusion:
> AC_RUN_IFELSE(
> [AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT],
> [[
> FILE *f = fopen(".", "r");
> return f != NULL;]])],
> [ac_cv_fread_reads_directories=no],
> [ac_cv_fread_reads_directories=yes])
> ])
Jess
next prev parent reply other threads:[~2020-04-22 18:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 15:33 [PATCH] config.mak.uname: Define FREAD_READS_DIRECTORIES for GNU/Hurd Jessica Clarke
2020-04-22 16:41 ` Jonathan Nieder
2020-04-22 17:48 ` Junio C Hamano
2020-04-22 18:48 ` Brandon Casey
2020-04-22 18:50 ` Jessica Clarke [this message]
2020-04-22 19:05 ` Brandon Casey
2020-04-22 18:54 ` Brandon Casey
2020-04-22 19:13 ` Brandon Casey
2020-04-22 19:58 ` Jeff King
2020-04-22 21:18 ` Brandon Casey
2020-04-24 5:51 ` Jeff King
2020-04-22 17:18 ` Junio C Hamano
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=452EC7D1-BE96-4172-8F70-3E7384C87280@jrtc27.com \
--to=jrtc27@jrtc27.com \
--cc=drafnel@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
/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).