This commit is contained in:
martin 2014-05-06 08:42:32 +00:00 committed by admin
parent 3c28f96dd4
commit 40e0a83d29

View file

@ -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 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... 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... 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: Here's an konsole session to show this behaviour: