diff options
| author |  Joey Hess <joey@kitenet.net> | 2014-06-09 14:43:49 -0400 |
|---|---|---|
| committer | Joey Hess <joey@kitenet.net> | 2014-06-09 14:43:49 -0400 |
| commit | b29694b2e61d5f0ca36a3709eb7f76fdf3a739a5 (patch) | |
| tree | 4b0548bd8c313e73e21a41b4662b6a57ceef964e /doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment | |
| parent | c9e8ad671de1da7e75d45973109d223c9d4e8e81 (diff) | |
| parent | ce9cccb1f571028f3b697380422d07426803efb8 (diff) | |
Merge branch 'master' of ssh://git-annex.branchable.com
Diffstat (limited to 'doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment')
| -rw-r--r-- | doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment | 22 |
1 files changed, 22 insertions, 0 deletions
diff --git a/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment new file mode 100644 index 000000000..94cbad0e6 --- /dev/null +++ b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="martin" + ip="89.183.56.177" + subject="use case and answer to joey's question "...then when..."" + date="2014-06-08T04:59:42Z" + content=""" +Hi joey, + +i really think we should repair the timestamp instead of force the user to `git-annex add` possibly corrupted files/content (see your comment above) git-annex checksums are excellent for data integrity but they are useless if we bypass them in case of adding and propagating +potentially corrupted content with `git-annex add` + +So here's for example a useful use case: + +1. user fills his transfer repo in town A. He checks (`git annex fsck`) that everything is fine. He unmounts the drive and travels to town B. + +2. In town B user mounts the drive and sees, that he suddenly doesn't have \"access\" to those \"crippled files\" on his transfer repo (the files seems modified for the user without a reason - why should he `git-annex add` them again?? - he'd rather think about data corruption) . He wonders whats going on and thats why he does a + +3. `git-annex fsck` . `git annex fsck` should checksum also such crippled files, should report correct checksums if they are correct (so that the users knows their usb drive is working properly) and should give a message like this: \"checksum ok - crippled timestamp - repair with git-annex fsck --repair-timestamp or define a modify window \"- (to be implemented - in rsync the problem is already solved with this option \"--modify-window=NUM compare mod-times with reduced accuracy\") + +In my case distance between town B and town A was approx 400km and in town B i didnt know what was going on. So i went back to town A without success for further investigation of my usb drive... :-(( + +"""]] |