Subject: Re: What's cooking in git.git (Apr 2021, #04; Thu, 15)

From: Junio C Hamano <[email-masked]>
Date: Fri, 16 Apr 2021 06:33:07 -0700

Johannes Schindelin <[email-masked]> writes:

> Seems that this fixes it for me:

I can see that we avoid passing X_OK to _waccess() for normal paths
(outside the post context of this hunk).  Hence, it is consistent to
answer "yes" if somebody ever asks if NUL (/dev/null) is executable.

IOW, unconditional return of 0 this patch adds is the right thing to
do.

Thanks for a quick turnaround.

> -- snipsnap --
> From 754593d6bda3754ab4afaa98b814351e922a1fe3 Mon Sep 17 00:00:00 2001
> From: Johannes Schindelin <[email-masked]>
> Date: Fri, 16 Apr 2021 13:11:05 +0200
> Subject: [PATCH] msvc: avoid calling `access("NUL", flags)`
>
> Apparently this is not supported with Microsoft's Universal C Runtime.
> So let's not actually do that.
>
> Instead, just return success because we _know_ that we expect the `NUL`
> device to be present.
>
> Side note: it is possible to turn off the "Null device driver" and
> thereby disable `NUL`. Too many things are broken if this driver is
> disabled, therefore it is not worth bothering to try to detect its
> presence when `access()` is called.
>
> Signed-off-by: Johannes Schindelin <[email-masked]>
> ---
>  compat/mingw.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index a43599841c6c..aa647b367b0f 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -685,6 +685,8 @@ ssize_t mingw_write(int fd, const void *buf, size_t len)
>  int mingw_access(const char *filename, int mode)
>  {
>  	wchar_t wfilename[MAX_PATH];
> +	if (!strcmp("nul", filename) || !strcmp("/dev/null", filename))
> +		return 0;
>  	if (xutftowcs_path(wfilename, filename) < 0)
>  		return -1;
>  	/* X_OK is not supported by the MSVCRT version */
> --
> 2.31.1.windows.1