Re: [PATCH 0/3] Win32: nanosecond-precision file times

Karsten Blees [off-list ref] writes:

However, the Makefile has this to say on the subject:

# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
# randomly break unless your underlying filesystem supports those sub-second
# times (my ext3 doesn't).

Am I missing something?

I think "it would break" is about show-diff which wanted to use the
cached stat information for freshness.

	>foo
	git update-index --add foo
        sleep 2
        >foo
        git diff-files ;# modern counterpart of show-diff

would say that "foo" is *different*, because the plumbing commands
like diff-files expect you to refresh the index before you call
them.

And if you did "git update-index --refresh" after touching "foo" the
last time before running "git diff-files" in the above sequence, you
should expect that it does not say "foo" is different, no matter how
much time passes between the time you run that "refresh" and
"diff-files" (or between the time you last touched "foo" and you run
"refresh", for that matter), as long as you do not touch "foo" in
the meantime.  The following should say "foo" is *not* different,
that is:

	>foo
	git update-index --add foo
        sleep 2
        >foo
        sleep arbitrary
        git update-index --refresh
        sleep arbitrary
        git diff-files ;# modern counterpart of show-diff

If you use NSEC, however, and "refresh" grabbed a subsecond time and
then later "diff-files" learned a truncated/rounded time because the
filesystem later purged the cached inodes and re-read it from the
underlying filesystem with no subsecond time resolution, the times
would not match so you will again see "diff-files" report that "foo"
is now different.

That is what the comment you cited is about.

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Am 16.02.2015 um 23:10 schrieb Junio C Hamano:

Karsten Blees [off-list ref] writes:

quoted

However, the Makefile has this to say on the subject:

# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
# randomly break unless your underlying filesystem supports those sub-second
# times (my ext3 doesn't).

Am I missing something?

[...]

If you use NSEC, however, and "refresh" grabbed a subsecond time and
then later "diff-files" learned a truncated/rounded time because the
filesystem later purged the cached inodes and re-read it from the
underlying filesystem with no subsecond time resolution, the times
would not match so you will again see "diff-files" report that "foo"
is now different.

That is what the comment you cited is about.

OK, so it all boils down to the "inode cache doesn't round to on-disk
resolution" issue after all, as explained in racy-git.txt.

But then the Makefile comment is quite misleading. Enabling USE_NSEC
will not unconditionally "BREAK YOUR LOCAL DIFFS". Show-diff / diff-files
will also not "break", but may report false positives instead (which may
be worse than failing hard...).

It also seems to me that this is a Linux-only issue which is only remotely
related to the USE_NSEC setting or file systems' timestamp resolutions.

The kernel patch referenced in racy-git.txt only addresses sub-second
resolutions. So even if USE_NSEC is *disabled*, the diff-files issue will
bite you on e.g. FAT32-formatted flash-drives on Linux, at least on
re-mount ("sync && echo 2>/proc/sys/vm/drop_caches" didn't seem to trigger
the rounding, though).

I also suspect that the sub-second rounding function of that patch
(timespec_trunc()) takes some invalid shortcuts - if you configure the
kernel for 300 jiffies per second (i.e. 3,333,333 ns per tick), UDF, NTFS,
SMBFS and CIFS file times will most likely not be properly rounded in the
inode cache. Haven't tested this, though.

So the only file systems with reliable file times on Linux seem to be
those with exactly 1s or 1ns resolution...?

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.