mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

high-res mtimes

Browse source 
Cache high-resolution mtimes for improved detection of modified files in v7
(and direct mode).

Including on Windows.

With back-compat support so old low-res mtimes won't break anything, and
so the new information also won't break old versions of git-annex.
This commit is contained in:
Joey Hess 2018-10-30 00:40:17 -04:00
parent 48af284872
commit 5ab0f48ffb
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
7 changed files with 109 additions and 31 deletions
Download patch file Download diff file Expand all files Collapse all files

9
doc/todo/v7_InodeCache_timestamp_resolution.mdwn
View file

@ -6,13 +6,18 @@ started checking the InodeCache to see if a file is modified.
This means that modifying a file, running `git add`, then modifying again
and `git add` within the same second won't stage the second version of the
file.
file. (Although luckily it also compares file size.)
I think that optimisation needs to be disabled when inode caches will be
compared weakly, because 2 seconds is just too long. This will mean slow
`git checkout` on FAT and also when a user moves a repo to a different
filesystem. But I don't see a way to avoid it.
> Hmm, on second thought, that would mean every inAnnex on FAT
> would need to checksum the content. That's just too slow to be practical.
> `git annex fsck` will clean up if trusting the timestamps causes
> it to make a mistake on FAT.
Otherwise, the problem can be fixed by using modificationTimeHiRes.
But! All existing InodeCaches would then appear to have changed. This would
@ -36,4 +41,4 @@ What would work, w/o breaking back-compat is
So the decimal part of the mtime becomes the 4th word and old
versions of git-annex will ignore it.
--[[Joey]]
> [[fixed|done]] --[[Joey]]