From 40e0a83d296fd8cd22be1b78a1923a53d16a2065 Mon Sep 17 00:00:00 2001 From: martin Date: Tue, 6 May 2014 08:42:32 +0000 Subject: [PATCH] --- .../FAT:_Date_resolution_for_mtime_2s--__62___implications.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/FAT:_Date_resolution_for_mtime_2s--__62___implications.mdwn b/doc/forum/FAT:_Date_resolution_for_mtime_2s--__62___implications.mdwn index 3f4bbccd8b..0deb3ceab6 100644 --- a/doc/forum/FAT:_Date_resolution_for_mtime_2s--__62___implications.mdwn +++ b/doc/forum/FAT:_Date_resolution_for_mtime_2s--__62___implications.mdwn @@ -2,7 +2,7 @@ The Date resolution of the FAT filesystem is only 2 seconds for the "last modifi This leads to the strange behaviour, that after umount and remount of an usb drive (direct mode) git-annex thinks that suddenly approx. 50% of the files are modified. (after remount the "seconds" appears to be rounded to even values - the inode cache before unmount had 1 second resolution) So git-annex is not real "guilty" but it would be fine to create a "workaround" for this problem... -Possible the best solution for this is to set even values for the seconds in the filesystem and in annex internal tables direct after the "git annex get". +Possible the best solution for this is to set even values for the seconds in the filesystem and in annex internal tables direct after the `git annex get`. Other solution would be to treat differences up to 1s in modification time as unmodified or create an new parameter like rsync's "modify-window" for this. 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... Here's an konsole session to show this behaviour: