This commit is contained in:
parent
4c08cd5c0a
commit
af79cf93ef
1 changed files with 1 additions and 1 deletions
|
@ -1,6 +1,6 @@
|
||||||
The Date resolution for FAT is only 2 seconds for the "last modified time."
|
The Date resolution for FAT 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
|
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 files are modified. (after remount the times appears to be rounded to even values) 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...
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue