# [PATCH] config.mak.uname: set FREAD_READS_DIRECTORIES for cygwin 2 messages from 2017-07-21 to 2017-07-21. Participants: Ramsay Jones, Junio C Hamano. Thread: https://gitlist.dev/t/46438 ## Ramsay Jones, 2017-07-21 18:43 Subject: [PATCH] config.mak.uname: set FREAD_READS_DIRECTORIES for cygwin Message-ID: <506cb9f2-cf59-2df6-2d4c-30c82dfbf85b@ramsayjones.plus.com> URL: https://gitlist.dev/e/506cb9f2-cf59-2df6-2d4c-30c82dfbf85b%40ramsayjones.plus.com ``` Signed-off-by: Ramsay Jones --- Hi Junio, My 'make test' run for the v2.14.0-rc0 on cygwin turned up a new test failure (over and above the v2.13.0 failures), namely t1308.23. Running the test in the debugger showed that cygwin was fopen-ing the 'a-directory' without problem. On one occasion, while in the debugger, I did see fopen return NULL while trying to open a directory. So, I created a test program which showed reliably that fopen succeeds on a directory. (So, maybe I was just seeing things! :-D ). t1308 was reliably failing before this patch, afterwards it reliably passes, so ... [I have a full test run going at the moment, but it won't finish for about 3 hours.] ATB, Ramsay Jones config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index 551e465a7..6604b130f 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -185,6 +185,7 @@ ifeq ($(uname_O),Cygwin) SPARSE_FLAGS = -isystem /usr/include/w32api -Wno-one-bit-signed-bitfield OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo COMPAT_OBJS += compat/cygwin.o + FREAD_READS_DIRECTORIES = UnfortunatelyYes endif ifeq ($(uname_S),FreeBSD) NEEDS_LIBICONV = YesPlease -- 2.13.0 ``` ## Junio C Hamano, 2017-07-21 19:28 Subject: Re: [PATCH] config.mak.uname: set FREAD_READS_DIRECTORIES for cygwin Message-ID: URL: https://gitlist.dev/e/xmqq4lu5h9nl.fsf%40gitster.mtv.corp.google.com In-Reply-To: <506cb9f2-cf59-2df6-2d4c-30c82dfbf85b@ramsayjones.plus.com> ``` Ramsay Jones writes: > Signed-off-by: Ramsay Jones > --- > > Hi Junio, > > My 'make test' run for the v2.14.0-rc0 on cygwin turned up a new > test failure (over and above the v2.13.0 failures), namely t1308.23. > Running the test in the debugger showed that cygwin was fopen-ing > the 'a-directory' without problem. > > On one occasion, while in the debugger, I did see fopen return NULL > while trying to open a directory. So, I created a test program which > showed reliably that fopen succeeds on a directory. (So, maybe I was > just seeing things! :-D ). > > t1308 was reliably failing before this patch, afterwards it reliably > passes, so ... > > [I have a full test run going at the moment, but it won't finish for > about 3 hours.] > > ATB, > Ramsay Jones Thanks. Let's apply it for -rc1. > > config.mak.uname | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/config.mak.uname b/config.mak.uname > index 551e465a7..6604b130f 100644 > --- a/config.mak.uname > +++ b/config.mak.uname > @@ -185,6 +185,7 @@ ifeq ($(uname_O),Cygwin) > SPARSE_FLAGS = -isystem /usr/include/w32api -Wno-one-bit-signed-bitfield > OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo > COMPAT_OBJS += compat/cygwin.o > + FREAD_READS_DIRECTORIES = UnfortunatelyYes > endif > ifeq ($(uname_S),FreeBSD) > NEEDS_LIBICONV = YesPlease ```