Re: [PATCH 0/3] Win32: nanosecond-precision file times
- From
Karsten Blees <karsten.blees@gmail.com>
- Date
- Feb 17, 2015, 21:57 UTC
- Message-ID
- <54E3B959.9040105@gmail.com>
- In-Reply-To
- <xmqqtwyl4idp.fsf@gitster.dls.corp.google.com>
Am 16.02.2015 um 23:10 schrieb Junio C Hamano:
Show 12 quoted lines
> Karsten Blees <karsten.blees@gmail.com> 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? >
[...]
Show 10 quoted lines
> > 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.