Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 <johannes.schindelin@xxxxxx>
> 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 <johannes.schindelin@xxxxxx>
> ---
> 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
