threads / patch / 18962

patch, 2 partsWindows: Skip fstat/lstat optimization in write_entry()

Subject: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

## tl;dr

12 messages between Apr 20, 2009 and Apr 20, 2009. Diffs are folded; open one to read it.

replies: 11people: 6as markdown or json

Johannes Sixt· Apr 20, 2009, 08:17 UTC · lore
From: Johannes Sixt <j6t@kdbg.org>

Commit e4c72923 (write_entry(): use fstat() instead of lstat() when file is open, 2009-02-09) introduced an optimization of write_entry(). Unfortunately, we cannot take advantage of this optimization on Windows because there is no guarantee that the time stamps are updated before the file is closed:

  "The only guarantee about a file timestamp is that the file time is
   correctly reflected when the handle that makes the change is closed."
(http://msdn.microsoft.com/en-us/library/ms724290(VS.85).aspx)

The failure of this optimization on Windows can be observed most easily by running a 'git checkout' that has to update several large files. In this case, 'git checkout' will report modified files, but infact only the timestamps were incorrectly recorded in the index, as can be verified by a subsequent 'git diff', which shows no change.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
 My gut feeling was right: We cannot have this optimization on Windows.
 http://thread.gmane.org/gmane.comp.version-control.git/108351/focus=108357
 I've a repository where I can reproduce the error quite easily and this
 fixes it.
 -- Hannes (who forgot to add Dscho and git@vger on the first send attempt)
 Makefile          |    8 ++++++++
 entry.c           |    3 ++-
 git-compat-util.h |    6 ++++++
 3 files changed, 16 insertions(+), 1 deletions(-)
Show changes to 3 files +16 −1

Makefile, entry.c, git-compat-util.h

diff --git a/Makefile b/Makefile
index 076a732..a01d603 100644
--- a/Makefile
+++ b/Makefile
@@ -167,6 +167,10 @@ all::
 # Define NO_EXTERNAL_GREP if you don't want "git grep" to ever call
 # your external grep (e.g., if your system lacks grep, if its grep is
 # broken, or spawning external process is slower than built-in grep git has).
+#
+# Define UNRELIABLE_FSTAT if your system's fstat does not return the same
+# information on a not yet closed file that lstat would return for the same
+# file after it was closed.

 GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
 	@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -833,6 +837,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
 	NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
 	NO_NSEC = YesPlease
 	USE_WIN32_MMAP = YesPlease
+	UNRELIABLE_FSTAT = UnfortunatelyYes
 	COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/regex -Icompat/fnmatch
 	COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1
 	COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
@@ -1111,6 +1116,9 @@ endif
 ifdef NO_EXTERNAL_GREP
 	BASIC_CFLAGS += -DNO_EXTERNAL_GREP
 endif
+ifdef UNRELIABLE_FSTAT
+	BASIC_CFLAGS += -DUNRELIABLE_FSTAT
+endif

 ifeq ($(TCLTK_PATH),)
 NO_TCLTK=NoThanks
diff --git a/entry.c b/entry.c
index 5daacc2..915514a 100644
--- a/entry.c
+++ b/entry.c
@@ -147,7 +147,8 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout

 		wrote = write_in_full(fd, new, size);
 		/* use fstat() only when path == ce->name */
-		if (state->refresh_cache && !to_tempfile && !state->base_dir_len) {
+		if (fstat_is_reliable() &&
+		    state->refresh_cache && !to_tempfile && !state->base_dir_len) {
 			fstat(fd, &st);
 			fstat_done = 1;
 		}
diff --git a/git-compat-util.h b/git-compat-util.h
index d94c683..bf00f35 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -409,4 +409,10 @@ void git_qsort(void *base, size_t nmemb, size_t size,
 #endif
 #endif

+#ifdef UNRELIABLE_FSTAT
+#define fstat_is_reliable() 0
+#else
+#define fstat_is_reliable() 1
+#endif
+
 #endif
-- 
1.6.3.rc1.989.ga175e.dirty
Johannes Schindelin· Apr 20, 2009, 10:05 UTC · re: Johannes Sixt · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

Hi,
On Mon, 20 Apr 2009, Johannes Sixt wrote:
Show 29 quoted lines
> From: Johannes Sixt <j6t@kdbg.org>
> 
> Commit e4c72923 (write_entry(): use fstat() instead of lstat() when file
> is open, 2009-02-09) introduced an optimization of write_entry().
> Unfortunately, we cannot take advantage of this optimization on Windows
> because there is no guarantee that the time stamps are updated before the
> file is closed:
> 
>   "The only guarantee about a file timestamp is that the file time is
>    correctly reflected when the handle that makes the change is closed."
> 
> (http://msdn.microsoft.com/en-us/library/ms724290(VS.85).aspx)
> 
> The failure of this optimization on Windows can be observed most easily by
> running a 'git checkout' that has to update several large files. In this
> case, 'git checkout' will report modified files, but infact only the
> timestamps were incorrectly recorded in the index, as can be verified by a
> subsequent 'git diff', which shows no change.
> 
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
>  My gut feeling was right: We cannot have this optimization on Windows.
> 
>  http://thread.gmane.org/gmane.comp.version-control.git/108351/focus=108357
> 
>  I've a repository where I can reproduce the error quite easily and this
>  fixes it.
> 
>  -- Hannes (who forgot to add Dscho and git@vger on the first send attempt)
You want this in 4msysgit's 'devel' branch, correct?

Ciao, Dscho "who is still interim maintainer ;-)"

Dmitry Potapov· Apr 20, 2009, 11:03 UTC · re: Johannes Sixt · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

The cygwin version has the same problem. (In fact, it is even worse, because we have an optimized version for lstat/stat but not for fstat, and they return different values for some fields like i_no). But even if we used the only Cygwin functions, we would still face the problem, because Windows returns the wrong values for timestamps (and maybe even size on FAT?). So I think the following patch should be squashed on top.

-- >8 --
From 1f957680d9b0e0bfeda9bf0e20397b0323b45334 Mon Sep 17 00:00:00 2001
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Mon, 20 Apr 2009 14:54:16 +0400
Subject: [PATCH] cygwin: Skip fstat/lstat optimization in write_entry()
---
 Makefile |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
Show changes to Makefile +1 −0
diff --git a/Makefile b/Makefile
index 2af0dfb..177dc15 100644
--- a/Makefile
+++ b/Makefile
@@ -809,6 +809,7 @@ ifeq ($(uname_S),HP-UX)
 endif
 ifneq (,$(findstring CYGWIN,$(uname_S)))
 	COMPAT_OBJS += compat/cygwin.o
+	UNRELIABLE_FSTAT = UnfortunatelyYes
 endif
 ifneq (,$(findstring MINGW,$(uname_S)))
 	NO_PREAD = YesPlease
-- 
1.6.1.20.gee856
-- >8 --
Hannu Koivisto· Apr 20, 2009, 12:34 UTC · re: Dmitry Potapov · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

Dmitry Potapov <dpotapov@gmail.com> writes:
Show 7 quoted lines
> The cygwin version has the same problem. (In fact, it is even worse,
> because we have an optimized version for lstat/stat but not for fstat,
> and they return different values for some fields like i_no). But even
> if we used the only Cygwin functions, we would still face the problem,
> because Windows returns the wrong values for timestamps (and maybe
> even size on FAT?). So I think the following patch should be squashed
> on top.

I can verify that this fixes the rebase problem I've been having in Cygwin and that I just mailed about separately.

-- 
Hannu
Alex Riesen· Apr 20, 2009, 12:58 UTC · re: Dmitry Potapov · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

2009/4/20 Dmitry Potapov <dpotapov@gmail.com>:
Show 7 quoted lines
> The cygwin version has the same problem. (In fact, it is even worse,
> because we have an optimized version for lstat/stat but not for fstat,
> and they return different values for some fields like i_no). But even
> if we used the only Cygwin functions, we would still face the problem,
> because Windows returns the wrong values for timestamps (and maybe
> even size on FAT?). So I think the following patch should be squashed
> on top.

I just sent a patch with an "optimized" fstat. I see no problems (at least none like these) with that patch. Timestamps match. Windows XP, yes. But since that MSDN article mentions that it is not guaranteed, I guess I just been lucky.

Dmitry Potapov· Apr 20, 2009, 13:33 UTC · re: Alex Riesen · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

On Mon, Apr 20, 2009 at 02:58:49PM +0200, Alex Riesen wrote:
Show 12 quoted lines
> 2009/4/20 Dmitry Potapov <dpotapov@gmail.com>:
> > The cygwin version has the same problem. (In fact, it is even worse,
> > because we have an optimized version for lstat/stat but not for fstat,
> > and they return different values for some fields like i_no). But even
> > if we used the only Cygwin functions, we would still face the problem,
> > because Windows returns the wrong values for timestamps (and maybe
> > even size on FAT?). So I think the following patch should be squashed
> > on top.
> 
> I just sent a patch with an "optimized" fstat. I see no problems (at least none
> like these) with that patch. Timestamps match. Windows XP, yes. But since
> that MSDN article mentions that it is not guaranteed, I guess I just been lucky.

If the time passed between the creating file and end of writing to it is small (less than timestamp resolution), you may not notice the problem. The following program demonstrates the problem with fstat on Windows. (I compiled it using Cygwin). If you remove 'sleep' then you may not notice the problem for a long time.

-- >8 -- #include <stdio.h> #include <string.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>

#define FILENAME "stat-test.tmp"
int main()
{
	struct stat st1, st2;
	memset(&st1, 0, sizeof(st1));
	memset(&st2, 0, sizeof(st2));
	unlink(FILENAME);
	int fd = open(FILENAME, O_CREAT|O_RDWR|O_TRUNC, S_IRWXU);
	if (fd == -1)
	{
		perror("Cannot open " FILENAME);
		return -1;
	}
	sleep(1); /* It is IMPORTANT! */
	write(fd, "test\n", 5);
	fstat(fd, &st1);
	close(fd);
	lstat(FILENAME, &st2);
	if (memcmp(&st1, &st2, sizeof(st1))==0)
		printf("fstat is OK\n");
	else
		printf("fstat is broken\n");
	return 0;
}
-- >8 --
Dmitry
Alex Riesen· Apr 20, 2009, 13:54 UTC · re: Dmitry Potapov · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

2009/4/20 Dmitry Potapov <dpotapov@gmail.com>:
Show 19 quoted lines
> On Mon, Apr 20, 2009 at 02:58:49PM +0200, Alex Riesen wrote:
>> 2009/4/20 Dmitry Potapov <dpotapov@gmail.com>:
>> > The cygwin version has the same problem. (In fact, it is even worse,
>> > because we have an optimized version for lstat/stat but not for fstat,
>> > and they return different values for some fields like i_no). But even
>> > if we used the only Cygwin functions, we would still face the problem,
>> > because Windows returns the wrong values for timestamps (and maybe
>> > even size on FAT?). So I think the following patch should be squashed
>> > on top.
>>
>> I just sent a patch with an "optimized" fstat. I see no problems (at least none
>> like these) with that patch. Timestamps match. Windows XP, yes. But since
>> that MSDN article mentions that it is not guaranteed, I guess I just been lucky.
>
> If the time passed between the creating file and end of writing to it is
> small (less than timestamp resolution), you may not notice the problem.
> The following program demonstrates the problem with fstat on Windows.
> (I compiled it using Cygwin). If you remove 'sleep' then you may not
> notice the problem for a long time.

And the Windows being as slow as it is, the problem can stay undetected for a long time in a real working code.

Johannes Sixt· Apr 20, 2009, 14:19 UTC · re: Alex Riesen · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

Alex Riesen schrieb:
Show 9 quoted lines
> 2009/4/20 Dmitry Potapov <dpotapov@gmail.com>:
>> If the time passed between the creating file and end of writing to it is
>> small (less than timestamp resolution), you may not notice the problem.
>> The following program demonstrates the problem with fstat on Windows.
>> (I compiled it using Cygwin). If you remove 'sleep' then you may not
>> notice the problem for a long time.
> 
> And the Windows being as slow as it is, the problem can stay undetected for
> a long time in a real working code.

You got that wrong: If Windows were slow, the error would have been triggered more often and it would have been detected earlier. There you have the proof: Windows is fast ... enough :-P

-- Hannes
Alex Riesen· Apr 20, 2009, 14:25 UTC · re: Johannes Sixt · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

2009/4/20 Johannes Sixt <j.sixt@viscovery.net>:
Show 14 quoted lines
> Alex Riesen schrieb:
>> 2009/4/20 Dmitry Potapov <dpotapov@gmail.com>:
>>> If the time passed between the creating file and end of writing to it is
>>> small (less than timestamp resolution), you may not notice the problem.
>>> The following program demonstrates the problem with fstat on Windows.
>>> (I compiled it using Cygwin). If you remove 'sleep' then you may not
>>> notice the problem for a long time.
>>
>> And the Windows being as slow as it is, the problem can stay undetected for
>> a long time in a real working code.
>
> You got that wrong: If Windows were slow, the error would have been
> triggered more often and it would have been detected earlier. There you
> have the proof: Windows is fast ... enough :-P
Err, yes. Still a piece of cpp junk
Alex Riesen· Apr 20, 2009, 14:27 UTC · re: Alex Riesen · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

2009/4/20 Alex Riesen <raa.lkml@gmail.com>:
Show 7 quoted lines
> 2009/4/20 Johannes Sixt <j.sixt@viscovery.net>:
>> You got that wrong: If Windows were slow, the error would have been
>> triggered more often and it would have been detected earlier. There you
>> have the proof: Windows is fast ... enough :-P
>
> Err, yes. Still a piece of cpp junk
>
Err, a _pile_.
Junio C Hamano· Apr 20, 2009, 21:17 UTC · re: Dmitry Potapov · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

Dmitry Potapov <dpotapov@gmail.com> writes:
Show 19 quoted lines
> On Mon, Apr 20, 2009 at 02:58:49PM +0200, Alex Riesen wrote:
>> 2009/4/20 Dmitry Potapov <dpotapov@gmail.com>:
>> > The cygwin version has the same problem. (In fact, it is even worse,
>> > because we have an optimized version for lstat/stat but not for fstat,
>> > and they return different values for some fields like i_no). But even
>> > if we used the only Cygwin functions, we would still face the problem,
>> > because Windows returns the wrong values for timestamps (and maybe
>> > even size on FAT?). So I think the following patch should be squashed
>> > on top.
>> 
>> I just sent a patch with an "optimized" fstat. I see no problems (at least none
>> like these) with that patch. Timestamps match. Windows XP, yes. But since
>> that MSDN article mentions that it is not guaranteed, I guess I just been lucky.
>
> If the time passed between the creating file and end of writing to it is
> small (less than timestamp resolution), you may not notice the problem.
> The following program demonstrates the problem with fstat on Windows.
> (I compiled it using Cygwin). If you remove 'sleep' then you may not
> notice the problem for a long time.

I take that you mean that Alex's patch does not work as intended. In the meantime, I've squashed your one-liner "Cygwin-too" into Hannes's patch.

Thanks.
Alex Riesen· Apr 20, 2009, 22:17 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/2] Windows: Skip fstat/lstat optimization in write_entry()

2009/4/20 Junio C Hamano <gitster@pobox.com>:
Show 9 quoted lines
> Dmitry Potapov <dpotapov@gmail.com> writes:
>>
>> If the time passed between the creating file and end of writing to it is
>> small (less than timestamp resolution), you may not notice the problem.
>> The following program demonstrates the problem with fstat on Windows.
>> (I compiled it using Cygwin). If you remove 'sleep' then you may not
>> notice the problem for a long time.
>
> I take that you mean that Alex's patch does not work as intended.  ...
Yes, it just makes the problem harder to notice by providing a faster fstat.

← back to recent threads