Merge branch 'master' of ssh://git-annex.branchable.com

9 files changed, 189 insertions, 0 deletions

diff --git a/doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate/comment_6_ce01656b191d2bb13a3ddc29794e1e7a._comment b/doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate/comment_6_ce01656b191d2bb13a3ddc29794e1e7a._comment
new file mode 100644
index 000000000..fd589eb18
--- /dev/null
+++ b/doc/bugs/Assistant_doesn__39__t_keep_separate_local_repositories_100__37___separate/comment_6_ce01656b191d2bb13a3ddc29794e1e7a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmi0jblSiI4c5-EswqKw4PXkx5M4fuVvdk"
+ nickname="Henry"
+ subject="comment 6"
+ date="2014-06-11T16:31:09Z"
+ content="""
+I've just installed 5.20140606 from sid and the problem is gone :-)
+
+Now hoping that this or one of the next release will make it into wheezy backports ;-)
+
+Thank you for your great work and support and sorry for my late feedback.
+"""]]
diff --git a/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_10_13a35801805ea3d2d4428b1539f96b16._comment b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_10_13a35801805ea3d2d4428b1539f96b16._comment
new file mode 100644
index 000000000..fdd123103
--- /dev/null
+++ b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_10_13a35801805ea3d2d4428b1539f96b16._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="martin"
+ ip="193.174.111.250"
+ subject="specification"
+ date="2014-06-11T05:43:02Z"
+ content="""
+What you suggested (to not add if exact 1s or exact 1h time difference and changed checksum) would do the trick but it's hard for the user to test if this really works as expected and it would be more secure and IMHO more clear to do it like this:
+
+If `git annex add` \"meets\" such files, `git annex add` should not really add / commit these pseudo-modified files but *only adapt the timestamps* (which make the software erroneously thinks the files were modified) to the vfat values. (if checksum is still correct) I guess the timestamps are in the annex branch. 
+
+`git annex add` could - instead of write: \"add ok\" - only write: \"corrected timestamp ok - no need to add\"
+
+So the user sees whats really happen and after this these files appears again as what they are: unmodified. `git annex status` would say nothing (everything fine), and `git annex fsck` would checksum these files again.
+
+I suppose that the way i suggest is harder to code :-( Unfortunately I'm not a good coder and not experienced in haskell for sending a patch myself / the open source way...
+
+
+"""]]
diff --git a/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_11_632456a0a1d399ee2bbac76b7d63a5f1._comment b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_11_632456a0a1d399ee2bbac76b7d63a5f1._comment
new file mode 100644
index 000000000..2605d69ab
--- /dev/null
+++ b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_11_632456a0a1d399ee2bbac76b7d63a5f1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 11"
+ date="2014-06-11T17:22:12Z"
+ content="""
+@martin, to the best of my knowledge and testing, what you're proposing `git annex add` do in this case is identical to what it already happens to do, except for the message displayed.
+
+Do you have an example of it not doing that?
+
+We seem to be talking past one-another, since I've now said three times this is what it does. And I've tested it twice.
+
+I don't think that the current behavior of add, or your suggested behavior (which again, happens to be nearly identical) is sufficient to close this bug report with.
+"""]]
diff --git a/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment
new file mode 100644
index 000000000..8d06ee857
--- /dev/null
+++ b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 12"
+ date="2014-06-11T18:05:48Z"
+ content="""
+The resolution problem does not seems to affect Windows, at least not on NTFS. In my tests, the mtime is fully preserved across reboots there.
+
+However, any change to the timezone on Windows does manage to mess up all the timestamps. Presumably this same flawed approach is used for DST adjustments.
+
+Example from inode cache after a 1 hour time zone change, which forced git-annex add to re-checksum:
+
+<pre>
+--1 2221 1395843799
++-1 2221 1395847399
+</pre>
+
+Of course, not all time zones are 1 hour offset, so as a heuristic, treating timestamps +- 60*60*Int as the same, would be pretty bad. Instead, it would probably make sense, on windows, to normalize the timestamp, using the current time zone, to get to the UTC timestamp. (Of course on unix, a file's timestamp is always given in UTC.)
+
+Unfortunately, Data.Time.LocalTime.getCurrentTimeZone doesn't seem to really work on windows. It always returns UTC+1 in my tests.
+
+Anyway, I'm now looking at this as two separate problems, the Windows Time Zone Sucks problem and the FAT Metadata Sucks problem. They will probably have different solutions..
+"""]]
diff --git a/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_13_962cd8d7280cbc1d61778d69f3a393f0._comment b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_13_962cd8d7280cbc1d61778d69f3a393f0._comment
new file mode 100644
index 000000000..0428fadbd
--- /dev/null
+++ b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_13_962cd8d7280cbc1d61778d69f3a393f0._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="FAT MetaData Sucks: an approach"
+ date="2014-06-11T18:15:59Z"
+ content="""
+git-annex already deals with FAT metadata sucking by using the inode sentinal file, to detect when a FAT filesystem has been remounted with new random inodes, and so ignore apparent inode changes.
+
+So, when a InodeCache is compared in weak mode due to that, it could just treat all mtimes within 2 seconds as the same. This would limit the brain-damange to FAT.
+
+One problem with this idea is that it's specific to linux's handling of FAT, with its random inodes. A FAT mounted on windows will have -1 for the inodes across remounts. So this method can't detect if a filesystem on windows is FAT, and has the problem, or NTFS and not. 
+
+But, I think the FAT side of this problem is also linux-specific. Linux dummies up good metadata for FAT, and then has to throw it away/degrade on unmount. Windows presumably uses real timestamps, with low resolution on FAT from the beginning.
+
+I don't know how eg OSX handles this. If it used constant inodes but cached higher resolution mtimes for FAT, this approach would not work there.
+"""]]
diff --git a/doc/bugs/On_Ubuntu_14.04_assistant_fails_to_create_new_setup/comment_3_8687c1d1c44d88a8ac13208273565d6c._comment b/doc/bugs/On_Ubuntu_14.04_assistant_fails_to_create_new_setup/comment_3_8687c1d1c44d88a8ac13208273565d6c._comment
new file mode 100644
index 000000000..4e497e240
--- /dev/null
+++ b/doc/bugs/On_Ubuntu_14.04_assistant_fails_to_create_new_setup/comment_3_8687c1d1c44d88a8ac13208273565d6c._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7eqCMh_B7mxE0tnchbr0JoYu11FUAFRY"
+ nickname="Stéphane"
+ subject="No git-annex process."
+ date="2014-06-11T17:55:56Z"
+ content="""
+> It sounds rather like the webapp is failing to create the repository. Although I would expect for it to show an error message in red beneath the repository path. OTOH, it also sounds like something (either the webapp or eg a manual git-annex run) set up a git-annex repository in ~/Documents.
+
+As told before, there was definitely no git repository there before the webapp tried to create one.
+
+> git-annex will be started automatically on login as long as ~/.config/git-annex/autostart lists a repository to use. If that file exists and contains ~/Documents then we'll know that the webapp successfully set up the repository.
+
+There exists a ~/.config/git-annex/autostart containing one line, the correct /home/mylogin/Documents path to the folder.
+
+There is no process with git or annex in its name when user logs on his desktop session.
+
+
+    $ grep . $(dpkg -L git-annex | grep -i desktop)
+    /usr/share/applications/git-annex.desktop:[Desktop Entry]
+    /usr/share/applications/git-annex.desktop:Type=Application
+    /usr/share/applications/git-annex.desktop:Version=1.0
+    /usr/share/applications/git-annex.desktop:Name=Git Annex
+    /usr/share/applications/git-annex.desktop:Comment=Track and sync the files in your Git Annex
+    /usr/share/applications/git-annex.desktop:Terminal=false
+    /usr/share/applications/git-annex.desktop:Exec=/usr/bin/git-annex webapp
+    /usr/share/applications/git-annex.desktop:Icon=git-annex
+    /usr/share/applications/git-annex.desktop:Categories=Network;FileTransfer;
+    /etc/xdg/autostart/git-annex.desktop:[Desktop Entry]
+    /etc/xdg/autostart/git-annex.desktop:Type=Application
+    /etc/xdg/autostart/git-annex.desktop:Version=1.0
+    /etc/xdg/autostart/git-annex.desktop:Name=Git Annex Assistant
+    /etc/xdg/autostart/git-annex.desktop:Comment=Autostart
+    /etc/xdg/autostart/git-annex.desktop:Terminal=false
+    /etc/xdg/autostart/git-annex.desktop:Exec=/usr/bin/git-annex assistant --autostart
+    /etc/xdg/autostart/git-annex.desktop:Categories=
+
+"""]]
diff --git a/doc/bugs/git-annex:_createSession:_permission_denied___40__Operation_not_permitted__41__/comment_3_1229d5ea8799f0a744b3f03f620df1ec._comment b/doc/bugs/git-annex:_createSession:_permission_denied___40__Operation_not_permitted__41__/comment_3_1229d5ea8799f0a744b3f03f620df1ec._comment
new file mode 100644
index 000000000..08e5d21e7
--- /dev/null
+++ b/doc/bugs/git-annex:_createSession:_permission_denied___40__Operation_not_permitted__41__/comment_3_1229d5ea8799f0a744b3f03f620df1ec._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9SYh6N-JUMkYkW4aOk55zC3Vr9KonDV4"
+ nickname="Florian"
+ subject="comment 3"
+ date="2014-06-11T18:29:38Z"
+ content="""
+I'm having the exact same issue on Arch.
+
+You said this fix was in the tarballs in one hour, which was almost two days ago. Are you refering to these downloads: http://downloads.kitenet.net/git-annex/linux/current/ I just wonder, because these show mtime of 5 days ago.
+
+Thx!
+"""]]
diff --git a/doc/forum/could_not_read_from_remote_repository/comment_2_cf7d5e231675921c3d98faab3613c92f._comment b/doc/forum/could_not_read_from_remote_repository/comment_2_cf7d5e231675921c3d98faab3613c92f._comment
new file mode 100644
index 000000000..6775d9278
--- /dev/null
+++ b/doc/forum/could_not_read_from_remote_repository/comment_2_cf7d5e231675921c3d98faab3613c92f._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnX1msQxnLoSeu7q-i-c9BWghonsN7Qmns"
+ nickname="Jan Ulrich"
+ subject="Same error after deleting .ssh/git-annex-shell"
+ date="2014-06-11T15:53:17Z"
+ content="""
+Hi,
+
+I get the error before and after I deleted .ssh/git-annex-shell on my Ubuntu desktop:
+
+    janulrimacbook2:Movies juh$ git annex sync
+    commit  ok
+    pull sokrates.local_Videos
+    bash: /home/juh/.ssh/git-annex-shell: Datei oder Verzeichnis nicht gefunden
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+    failed  
+    push sokrates.local_Videos
+    bash: /home/juh/.ssh/git-annex-shell: Datei oder Verzeichnis nicht gefunden 
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+
+      Pushing to sokrates.local_Videos failed.
+
+       (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+    failed
+    git-annex: sync: 2 failed
+
+Git-annex version on macbook:
+
+    git-annex version: 5.20140605-gc2add53
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+Git-annex version on Ubuntu desktop:
+
+    git-annex version: 5.20140517
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+"""]]
diff --git a/doc/videos/git-annex_assistant_lan/comment_3_d43ee0a335c2f010b437cf28437455c2._comment b/doc/videos/git-annex_assistant_lan/comment_3_d43ee0a335c2f010b437cf28437455c2._comment
new file mode 100644
index 000000000..39fb1aefc
--- /dev/null
+++ b/doc/videos/git-annex_assistant_lan/comment_3_d43ee0a335c2f010b437cf28437455c2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="Where is it registered?"
+ date="2014-06-11T11:27:02Z"
+ content="""
+I'm curious: how do you register it? Does it only work on Linux? (I've had to add paths to my setup under OS X, so it would be great if there was such a simpler way.)
+"""]]