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

Added a comment

Browse source
This commit is contained in:
http://joeyh.name/ 2014-06-05 17:06:40 +00:00 • committed by admin
parent 67f531cd1f
commit 11f4218682
1 changed files with 22 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_3_923fc470727ecf21f0bb368b0486b15d._comment Normal file
View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 3"
date="2014-06-05T17:06:40Z"
content="""
> if we have an exact time difference of 1s (probably \"inode problem\") or 1h (\"utc problem\") we treat this file as likely unmodified and check this via the normal checksum algorithm.
That sort of makes sense, but when is git-annex supposed to do that?
If `git annex add`, it already checksums the file, and already stages no change if the file's checksum is the same. And if the user has told git-annex to add the file and it's changed, the presumption is they know it's changed and want to add the new version.
> To do an git annex sync or git annex add is in my opinion not a good option, because one could add so Bad file content by accident...
If not in add or sync, then when?
----
I am actually having a hard time coming up with a scenario where this problem results in any more than extra checksumming work by git-annex.
The only scenario I see is: The drive is unmounted, gets corrupted, is remounted, and this timestamp nonsense causes git-annex to think a file (that has already gotten corrupted) has in fact changed, so it commits the corrupted version.
"""]]