Thread (1 message) 1 message, 1 author, 2021-04-16

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

From: Junio C Hamano <hidden>
Date: 2021-04-16 13:33:16

Johannes Schindelin [off-list ref] 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.

quoted hunk
-- snipsnap --
From 754593d6bda3754ab4afaa98b814351e922a1fe3 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <redacted>
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 <redacted>
---
 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help