{"thread":{"id":"49646","subject":"[PATCH 0/3] Use nanosecond-precision file times on Windows","startedAt":"2018-10-23T10:23:21Z","lastAt":"2018-10-25T09:35:53Z","messageCount":8,"participants":["Johannes Schindelin via GitGitGadget","Karsten Blees via GitGitGadget","brian m. carlson","Johannes Schindelin","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"361272","messageId":"pull.53.git.gitgitgadget@gmail.com","threadId":"49646","inReplyTo":null,"subject":"[PATCH 0/3] Use nanosecond-precision file times on Windows","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2018-10-23T10:23:18Z","receivedAt":"2018-10-23T10:23:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"This is yet another patch series in the slow wave of patches coming over\nfrom Git for Windows.\n\nWith this change, we now use preciser timestamps to determine e.g. whether\nthe Git index is out of date. This change made it into Git for Windows\nalready in version 2.6.0, i.e. for a little over three years.\n\nPlease note that this change originally caused a lot of trouble, as e.g.\nlibgit2 was unaware of our plans and used second-precision file times. So if\nyou used Git for Windows as well as a libgit2-based program to, say, update\nthe Git index, there would be a back-and-forth between index updates with\nand without the fractional second parts, causing quite a bit of bad\nperformance.\n\nThese issues have been ironed out long ago, though, so it is high time to\ncontribute these patches to core Git.\n\nJohannes Schindelin (1):\n mingw: factor out code to set stat() data\n\nKarsten Blees (2):\n mingw: replace MSVCRT's fstat() with a Win32-based implementation\n mingw: implement nanosecond-precision file times\n\n compat/mingw.c | 76 +++++++++++++++++++++++++++++++-----------------\n compat/mingw.h | 36 ++++++++++++++++-------\n config.mak.uname | 2 --\n 3 files changed, 76 insertions(+), 38 deletions(-)\n\n\nbase-commit: c4df23f7927d8d00e666a3c8d1b3375f1dc8a3c1\nPublished-As: https://github.com/gitgitgadget/git/releases/tags/pr-53%2Fdscho%2Fnanosecond-file-times-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-53/dscho/nanosecond-file-times-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/53\n-- \ngitgitgadget\n"},{"id":"361273","messageId":"85485598a8c391262612929ad4b98e79517e01a4.1540290197.git.gitgitgadget@gmail.com","threadId":"49646","inReplyTo":"pull.53.git.gitgitgadget@gmail.com","subject":"[PATCH 1/3] mingw: factor out code to set stat() data","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2018-10-23T10:23:19Z","receivedAt":"2018-10-23T10:23:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin \n\nIn our fstat() emulation, we convert the file metadata from Win32 data\nstructures to an emulated POSIX structure.\n\nTo structure the code better, let's factor that part out into its own\nfunction.\n\nNote: it would be tempting to try to unify this code with the part of\ndo_lstat() that does the same thing, but they operate on different data\nstructures: BY_HANDLE_FILE_INFORMATION vs WIN32_FILE_ATTRIBUTE_DATA. So\nunfortunately, they cannot be unified.\n\nSigned-off-by: Johannes Schindelin \n---\n compat/mingw.c | 39 +++++++++++++++++++++++++--------------\n 1 file changed, 25 insertions(+), 14 deletions(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 18caf2196..d2e7d86db 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -736,6 +736,29 @@ static int do_stat_internal(int follow, const char *file_name, struct stat *buf)\n \treturn do_lstat(follow, alt_name, buf);\n }\n \n+static int get_file_info_by_handle(HANDLE hnd, struct stat *buf)\n+{\n+\tBY_HANDLE_FILE_INFORMATION fdata;\n+\n+\tif (!GetFileInformationByHandle(hnd, &fdata)) {\n+\t\terrno = err_win_to_posix(GetLastError());\n+\t\treturn -1;\n+\t}\n+\n+\tbuf->st_ino = 0;\n+\tbuf->st_gid = 0;\n+\tbuf->st_uid = 0;\n+\tbuf->st_nlink = 1;\n+\tbuf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);\n+\tbuf->st_size = fdata.nFileSizeLow |\n+\t\t(((off_t)fdata.nFileSizeHigh)<<32);\n+\tbuf->st_dev = buf->st_rdev = 0; /* not used by Git */\n+\tbuf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));\n+\tbuf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));\n+\tbuf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));\n+\treturn 0;\n+}\n+\n int mingw_lstat(const char *file_name, struct stat *buf)\n {\n \treturn do_stat_internal(0, file_name, buf);\n@@ -748,7 +771,6 @@ int mingw_stat(const char *file_name, struct stat *buf)\n int mingw_fstat(int fd, struct stat *buf)\n {\n \tHANDLE fh = (HANDLE)_get_osfhandle(fd);\n-\tBY_HANDLE_FILE_INFORMATION fdata;\n \n \tif (fh == INVALID_HANDLE_VALUE) {\n \t\terrno = EBADF;\n@@ -758,20 +780,9 @@ int mingw_fstat(int fd, struct stat *buf)\n \tif (GetFileType(fh) != FILE_TYPE_DISK)\n \t\treturn _fstati64(fd, buf);\n \n-\tif (GetFileInformationByHandle(fh, &fdata)) {\n-\t\tbuf->st_ino = 0;\n-\t\tbuf->st_gid = 0;\n-\t\tbuf->st_uid = 0;\n-\t\tbuf->st_nlink = 1;\n-\t\tbuf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);\n-\t\tbuf->st_size = fdata.nFileSizeLow |\n-\t\t\t(((off_t)fdata.nFileSizeHigh)<<32);\n-\t\tbuf->st_dev = buf->st_rdev = 0; /* not used by Git */\n-\t\tbuf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));\n-\t\tbuf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));\n-\t\tbuf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));\n+\tif (!get_file_info_by_handle(fh, buf))\n \t\treturn 0;\n-\t}\n+\n \terrno = EBADF;\n \treturn -1;\n }\n-- \ngitgitgadget\n\n"},{"id":"361274","messageId":"f2ce9bdc01892b514f75c6c25c3393765593b1ca.1540290197.git.gitgitgadget@gmail.com","threadId":"49646","inReplyTo":"pull.53.git.gitgitgadget@gmail.com","subject":"[PATCH 2/3] mingw: replace MSVCRT's fstat() with a Win32-based implementation","fromName":"Karsten Blees via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2018-10-23T10:23:21Z","receivedAt":"2018-10-23T10:23:24Z","isPatch":true,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"From: Karsten Blees \n\nfstat() is the only stat-related CRT function for which we don't have a\nfull replacement yet (and thus the only reason to stick with MSVCRT's\n'struct stat' definition).\n\nFully implement fstat(), in preparation of implementing a POSIX 2013\ncompatible 'struct stat' with nanosecond-precision file times.\n\nThis allows us also to implement some clever code to handle pipes and\ncharacter devices in our own way.\n\nSigned-off-by: Karsten Blees \nSigned-off-by: Johannes Schindelin \n---\n compat/mingw.c | 31 +++++++++++++++++++++----------\n 1 file changed, 21 insertions(+), 10 deletions(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex d2e7d86db..07fc0b79a 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -771,20 +771,31 @@ int mingw_stat(const char *file_name, struct stat *buf)\n int mingw_fstat(int fd, struct stat *buf)\n {\n \tHANDLE fh = (HANDLE)_get_osfhandle(fd);\n+\tDWORD avail, type = GetFileType(fh) & ~FILE_TYPE_REMOTE;\n \n-\tif (fh == INVALID_HANDLE_VALUE) {\n-\t\terrno = EBADF;\n-\t\treturn -1;\n-\t}\n-\t/* direct non-file handles to MS's fstat() */\n-\tif (GetFileType(fh) != FILE_TYPE_DISK)\n-\t\treturn _fstati64(fd, buf);\n+\tswitch (type) {\n+\tcase FILE_TYPE_DISK:\n+\t\treturn get_file_info_by_handle(fh, buf);\n \n-\tif (!get_file_info_by_handle(fh, buf))\n+\tcase FILE_TYPE_CHAR:\n+\tcase FILE_TYPE_PIPE:\n+\t\t/* initialize stat fields */\n+\t\tmemset(buf, 0, sizeof(*buf));\n+\t\tbuf->st_nlink = 1;\n+\n+\t\tif (type == FILE_TYPE_CHAR) {\n+\t\t\tbuf->st_mode = _S_IFCHR;\n+\t\t} else {\n+\t\t\tbuf->st_mode = _S_IFIFO;\n+\t\t\tif (PeekNamedPipe(fh, NULL, 0, NULL, &avail, NULL))\n+\t\t\t\tbuf->st_size = avail;\n+\t\t}\n \t\treturn 0;\n \n-\terrno = EBADF;\n-\treturn -1;\n+\tdefault:\n+\t\terrno = EBADF;\n+\t\treturn -1;\n+\t}\n }\n \n static inline void time_t_to_filetime(time_t t, FILETIME *ft)\n-- \ngitgitgadget\n\n"},{"id":"361275","messageId":"1974831d2ebfd040fca574673bb7afcb9c0b15ef.1540290197.git.gitgitgadget@gmail.com","threadId":"49646","inReplyTo":"pull.53.git.gitgitgadget@gmail.com","subject":"[PATCH 3/3] mingw: implement nanosecond-precision file times","fromName":"Karsten Blees via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2018-10-23T10:23:22Z","receivedAt":"2018-10-23T10:23:27Z","isPatch":true,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"From: Karsten Blees \n\nWe no longer use any of MSVCRT's stat-functions, so there's no need to\nstick to a CRT-compatible 'struct stat' either.\n\nDefine and use our own POSIX-2013-compatible 'struct stat' with nanosecond-\nprecision file times.\n\nNote: This can cause performance issues when using Git variants with\ndifferent file time resolutions, as the timestamps are stored in the Git\nindex: after updating the index with a Git variant that uses\nsecond-precision file times, a nanosecond-aware Git will think that\npretty much every single file listed in the index is out of date.\n\nSigned-off-by: Karsten Blees \nSigned-off-by: Johannes Schindelin \n---\n compat/mingw.c | 18 ++++++++++--------\n compat/mingw.h | 36 ++++++++++++++++++++++++++----------\n config.mak.uname | 2 --\n 3 files changed, 36 insertions(+), 20 deletions(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 07fc0b79a..26016d02e 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -592,9 +592,11 @@ static inline long long filetime_to_hnsec(const FILETIME *ft)\n \treturn winTime - 116444736000000000LL;\n }\n \n-static inline time_t filetime_to_time_t(const FILETIME *ft)\n+static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)\n {\n-\treturn (time_t)(filetime_to_hnsec(ft) / 10000000);\n+\tlong long hnsec = filetime_to_hnsec(ft);\n+\tts->tv_sec = (time_t)(hnsec / 10000000);\n+\tts->tv_nsec = (hnsec % 10000000) * 100;\n }\n \n /**\n@@ -653,9 +655,9 @@ static int do_lstat(int follow, const char *file_name, struct stat *buf)\n \t\tbuf->st_size = fdata.nFileSizeLow |\n \t\t\t(((off_t)fdata.nFileSizeHigh)<<32);\n \t\tbuf->st_dev = buf->st_rdev = 0; /* not used by Git */\n-\t\tbuf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));\n-\t\tbuf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));\n-\t\tbuf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));\n+\t\tfiletime_to_timespec(&(fdata.ftLastAccessTime), &(buf->st_atim));\n+\t\tfiletime_to_timespec(&(fdata.ftLastWriteTime), &(buf->st_mtim));\n+\t\tfiletime_to_timespec(&(fdata.ftCreationTime), &(buf->st_ctim));\n \t\tif (fdata.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) {\n \t\t\tWIN32_FIND_DATAW findbuf;\n \t\t\tHANDLE handle = FindFirstFileW(wfilename, &findbuf);\n@@ -753,9 +755,9 @@ static int get_file_info_by_handle(HANDLE hnd, struct stat *buf)\n \tbuf->st_size = fdata.nFileSizeLow |\n \t\t(((off_t)fdata.nFileSizeHigh)<<32);\n \tbuf->st_dev = buf->st_rdev = 0; /* not used by Git */\n-\tbuf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));\n-\tbuf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));\n-\tbuf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));\n+\tfiletime_to_timespec(&(fdata.ftLastAccessTime), &(buf->st_atim));\n+\tfiletime_to_timespec(&(fdata.ftLastWriteTime), &(buf->st_mtim));\n+\tfiletime_to_timespec(&(fdata.ftCreationTime), &(buf->st_ctim));\n \treturn 0;\n }\n \ndiff --git a/compat/mingw.h b/compat/mingw.h\nindex 571019d0b..9419b27e1 100644\n--- a/compat/mingw.h\n+++ b/compat/mingw.h\n@@ -327,18 +327,41 @@ static inline int getrlimit(int resource, struct rlimit *rlp)\n }\n \n /*\n- * Use mingw specific stat()/lstat()/fstat() implementations on Windows.\n+ * Use mingw specific stat()/lstat()/fstat() implementations on Windows,\n+ * including our own struct stat with 64 bit st_size and nanosecond-precision\n+ * file times.\n */\n #ifndef __MINGW64_VERSION_MAJOR\n #define off_t off64_t\n #define lseek _lseeki64\n+struct timespec {\n+\ttime_t tv_sec;\n+\tlong tv_nsec;\n+};\n #endif\n \n-/* use struct stat with 64 bit st_size */\n+struct mingw_stat {\n+ _dev_t st_dev;\n+ _ino_t st_ino;\n+ _mode_t st_mode;\n+ short st_nlink;\n+ short st_uid;\n+ short st_gid;\n+ _dev_t st_rdev;\n+ off64_t st_size;\n+ struct timespec st_atim;\n+ struct timespec st_mtim;\n+ struct timespec st_ctim;\n+};\n+\n+#define st_atime st_atim.tv_sec\n+#define st_mtime st_mtim.tv_sec\n+#define st_ctime st_ctim.tv_sec\n+\n #ifdef stat\n #undef stat\n #endif\n-#define stat _stati64\n+#define stat mingw_stat\n int mingw_lstat(const char *file_name, struct stat *buf);\n int mingw_stat(const char *file_name, struct stat *buf);\n int mingw_fstat(int fd, struct stat *buf);\n@@ -351,13 +374,6 @@ int mingw_fstat(int fd, struct stat *buf);\n #endif\n #define lstat mingw_lstat\n \n-#ifndef _stati64\n-# define _stati64(x,y) mingw_stat(x,y)\n-#elif defined (_USE_32BIT_TIME_T)\n-# define _stat32i64(x,y) mingw_stat(x,y)\n-#else\n-# define _stat64(x,y) mingw_stat(x,y)\n-#endif\n \n int mingw_utime(const char *file_name, const struct utimbuf *times);\n #define utime mingw_utime\ndiff --git a/config.mak.uname b/config.mak.uname\nindex 8acdeb71f..f179d7a1d 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -370,7 +370,6 @@ ifeq ($(uname_S),Windows)\n \tRUNTIME_PREFIX = YesPlease\n \tHAVE_WPGMPTR = YesWeDo\n \tNO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease\n-\tNO_NSEC = YesPlease\n \tUSE_WIN32_MMAP = YesPlease\n \tMMAP_PREVENTS_DELETE = UnfortunatelyYes\n \t# USE_NED_ALLOCATOR = YesPlease\n@@ -518,7 +517,6 @@ ifneq (,$(findstring MINGW,$(uname_S)))\n \tRUNTIME_PREFIX = YesPlease\n \tHAVE_WPGMPTR = YesWeDo\n \tNO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease\n-\tNO_NSEC = YesPlease\n \tUSE_WIN32_MMAP = YesPlease\n \tMMAP_PREVENTS_DELETE = UnfortunatelyYes\n \tUSE_NED_ALLOCATOR = YesPlease\n-- \ngitgitgadget\n"},{"id":"361347","messageId":"20181024022024.GE6119@genre.crustytoothpaste.net","threadId":"49646","inReplyTo":"f2ce9bdc01892b514f75c6c25c3393765593b1ca.1540290197.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 2/3] mingw: replace MSVCRT's fstat() with a Win32-based implementation","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-10-24T02:20:24Z","receivedAt":"2018-10-24T02:59:45Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Oct 23, 2018 at 03:23:21AM -0700, Karsten Blees via GitGitGadget wrote:\n> -\tif (!get_file_info_by_handle(fh, buf))\n> +\tcase FILE_TYPE_CHAR:\n> +\tcase FILE_TYPE_PIPE:\n> +\t\t/* initialize stat fields */\n> +\t\tmemset(buf, 0, sizeof(*buf));\n> +\t\tbuf->st_nlink = 1;\n> +\n> +\t\tif (type == FILE_TYPE_CHAR) {\n> +\t\t\tbuf->st_mode = _S_IFCHR;\n> +\t\t} else {\n> +\t\t\tbuf->st_mode = _S_IFIFO;\n> +\t\t\tif (PeekNamedPipe(fh, NULL, 0, NULL, &avail, NULL))\n> +\t\t\t\tbuf->st_size = avail;\n\nThese lines strike me as a bit odd. As far as I'm aware, Unix systems\ndon't return anything useful in this field when calling fstat on a pipe.\nIs there a reason we fill this in on Windows? If so, could the commit\nmessage explain what that is?\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"361378","messageId":"nycvar.QRO.7.76.6.1810240927520.4546@tvgsbejvaqbjf.bet","threadId":"49646","inReplyTo":"20181024022024.GE6119@genre.crustytoothpaste.net","subject":"Re: [PATCH 2/3] mingw: replace MSVCRT's fstat() with a Win32-based implementation","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-10-24T07:37:43Z","receivedAt":"2018-10-24T07:37:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi brian,\n\nOn Wed, 24 Oct 2018, brian m. carlson wrote:\n\n> On Tue, Oct 23, 2018 at 03:23:21AM -0700, Karsten Blees via GitGitGadget wrote:\n> > -\tif (!get_file_info_by_handle(fh, buf))\n> > +\tcase FILE_TYPE_CHAR:\n> > +\tcase FILE_TYPE_PIPE:\n> > +\t\t/* initialize stat fields */\n> > +\t\tmemset(buf, 0, sizeof(*buf));\n> > +\t\tbuf->st_nlink = 1;\n> > +\n> > +\t\tif (type == FILE_TYPE_CHAR) {\n> > +\t\t\tbuf->st_mode = _S_IFCHR;\n> > +\t\t} else {\n> > +\t\t\tbuf->st_mode = _S_IFIFO;\n> > +\t\t\tif (PeekNamedPipe(fh, NULL, 0, NULL, &avail, NULL))\n> > +\t\t\t\tbuf->st_size = avail;\n> \n> These lines strike me as a bit odd. As far as I'm aware, Unix systems\n> don't return anything useful in this field when calling fstat on a pipe.\n> Is there a reason we fill this in on Windows? If so, could the commit\n> message explain what that is?\n\nAFAICT the idea was to imitate MSVCRT's fstat() in these cases.\n\nBut a quick web search suggests that you are right:\nhttps://bugzilla.redhat.com/show_bug.cgi?id=58768#c4 (I could not find any\nofficial documentation talking about fstat() and pipes, but I trust Alan\nto know their stuff).\n\nDo note, please, that according to the issue described in that link, at\nleast *some* glibc/Linux combinations behave in exactly the way this patch\nimplements it.\n\nAt this point, I am wary of changing this, too, as the code in question\nhas been in production (read: tested thoroughly) in the current form for\n*years*, and I am really loathe to introduce a bug where even\nWindows-specific code in compat/ might rely on this behavior. (And no, I\ndo not trust our test suite to find all of those use cases.)\n\nCiao,\nDscho\n"},{"id":"361437","messageId":"20181024224047.GF6119@genre.crustytoothpaste.net","threadId":"49646","inReplyTo":"nycvar.QRO.7.76.6.1810240927520.4546@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 2/3] mingw: replace MSVCRT's fstat() with a Win32-based implementation","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-10-24T22:40:47Z","receivedAt":"2018-10-24T22:40:56Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Wed, Oct 24, 2018 at 09:37:43AM +0200, Johannes Schindelin wrote:\n> Hi brian,\n> \n> On Wed, 24 Oct 2018, brian m. carlson wrote:\n> > These lines strike me as a bit odd. As far as I'm aware, Unix systems\n> > don't return anything useful in this field when calling fstat on a pipe.\n> > Is there a reason we fill this in on Windows? If so, could the commit\n> > message explain what that is?\n> \n> AFAICT the idea was to imitate MSVCRT's fstat() in these cases.\n> \n> But a quick web search suggests that you are right:\n> https://bugzilla.redhat.com/show_bug.cgi?id=58768#c4 (I could not find any\n> official documentation talking about fstat() and pipes, but I trust Alan\n> to know their stuff).\n\nYeah, that behavior is quite old. I'm surprised that Linux ever did\nthat.\n\n> Do note, please, that according to the issue described in that link, at\n> least *some* glibc/Linux combinations behave in exactly the way this patch\n> implements it.\n> \n> At this point, I am wary of changing this, too, as the code in question\n> has been in production (read: tested thoroughly) in the current form for\n> *years*, and I am really loathe to introduce a bug where even\n> Windows-specific code in compat/ might rely on this behavior. (And no, I\n> do not trust our test suite to find all of those use cases.)\n\nI don't feel strongly either way. I feel confident the rest of Git\ndoesn't use that field, so I don't see any downsides to keeping it other\nthan the slight overhead of populating it. I just thought I'd ask in\ncase there was something important I was missing.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"361498","messageId":"xmqq7ei6gyh8.fsf@gitster-ct.c.googlers.com","threadId":"49646","inReplyTo":"20181024224047.GF6119@genre.crustytoothpaste.net","subject":"Re: [PATCH 2/3] mingw: replace MSVCRT's fstat() with a Win32-based implementation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-25T09:35:47Z","receivedAt":"2018-10-25T09:35:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> Yeah, that behavior is quite old. I'm surprised that Linux ever did\n> that.\n> ...\n> I don't feel strongly either way. I feel confident the rest of Git\n> doesn't use that field, so I don't see any downsides to keeping it other\n> than the slight overhead of populating it. I just thought I'd ask in\n> case there was something important I was missing.\n\nOK, I'd consider that this part of the review settled for taking the\npatch as-is. Let's mark the topic for merging to 'next' soonish in\nthe what's cooking report.\n\nThanks.\n"}]}