From 5c573c82ddb38d1f4b1d8f2e31264724018c88a0 Mon Sep 17 00:00:00 2001 From: martin Date: Mon, 5 May 2014 15:36:56 +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 5ede475d2c..84955c83e8 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 @@ -1,6 +1,6 @@ The Date resolution of the FAT filesystem is only 2 seconds for the "last modified time." 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 times 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... +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". 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...