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

4 files changed, 65 insertions, 0 deletions

diff --git a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment b/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment
new file mode 100644
index 000000000..7ba073402
--- /dev/null
+++ b/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kubaello@d561f15ff5c07a78b706b096375cd89d6d706066"
+ nickname="kubaello"
+ avatar="http://cdn.libravatar.org/avatar/df2d1d9871b92552b99c3bacf442d739"
+ subject="comment 2"
+ date="2017-03-16T01:22:44Z"
+ content="""
+I came across the same problem today and I think I've found a workaround: [long paths on windows 10 - workaround](https://git-annex.branchable.com/forum/long_paths_on_windows_10_-_workaround/). It turns out Windows 10 allows enabling support for long paths with a single registry modification - unfortunately it is a system level setting, so it can potentially break some other programs.
+"""]]
diff --git a/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn b/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn
new file mode 100644
index 000000000..852a6045c
--- /dev/null
+++ b/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+
+can't fetch in parallel from a host over ssh if authentication is password-based
+
+### What steps will reproduce the problem?
+
+try to  get -J4  from a host which has ssh authentication password-only (no key)
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170101+gitg93d69b1-1~ndall+1
+with newer version (6.20170220+gitg75a15e1ad-1~ndall+1) looks slightly different but to the same "effect"
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git annex get -J4
+get sourcedata/sub-sid000004/ses-siemens0/anat/sub-sid000004_ses-siemens0_acq-MPRAGE_run-01_T1w.dicom.tgz get sourcedata/sub-sid000004/ses-siemens0/fmap/sub-sid000004_ses-siemens0_acq-3mm_run-01_phasediff.dicom.tgz get sourcedata/sub-sid000005/ses-siemens1/func/sub-sid000005_ses-siemens1_task-life_acq-2mm692_run-04_bold.dicom.tgz get sourcedata/sub-sid000005/ses-siemens1/func/sub-sid000005_ses-siemens1_task-life_acq-2mm748_run-03_bold.dicom.tgz (transfer already in progress, or unable to take transfer lock) 
+  Unable to access these remotes: origin
+(from origin...) (from origin...) 
+  Try making some of these repositories available:
+
+
+  	2e44be07-8f1a-4c11-a7cb-464802b87b26 -- mvdoc@smaug:/mnt/btrfs/dbic/inbox/dbic-ds-3mm/dbic/pulse_sequences
+   	b2ff2964-c31b-4784-b094-2bebb336da91 -- mvdoc@smaug:/mnt/btrfs/dbic/inbox/dbic-ds/dbic/pulse_sequences
+   	d486ea11-98dc-42d3-9640-e5713acfb675 -- yoh@rolando:/inbox/BIDS/dbic/1000-dbic-dataset [origin]
+failed
+get sourcedata/sub-sid000005/ses-siemens1/func/sub-sid000005_ses-siemens1_task-life_acq-2mm754_run-05_bold.dicom.tgz (from origin...) 
+(from origin...) 
+...
+yohtest@rolando.cns's password: yohtest@rolando.cns's password: yohtest@rolando.cns's password: yohtest@rolando.cns's password
+
+"""]]
+
+I have entered password just once -- didn't try to enter it multiple times into the void ;)  but I guess it would be neat if annex could handle this situation gracefully (e.g. initiate central ssh controller first before spawning parallel getters) and demand password once
+
+
+[[!meta author=yoh]]
diff --git a/doc/forum/long_paths_on_windows_10_-_workaround.mdwn b/doc/forum/long_paths_on_windows_10_-_workaround.mdwn
new file mode 100644
index 000000000..b51bcac5c
--- /dev/null
+++ b/doc/forum/long_paths_on_windows_10_-_workaround.mdwn
@@ -0,0 +1,9 @@
+It seems git-annex has some serious problems with long paths on windows systems. I would like to suggest a possible solution and a simple workaround.
+
+## Possible solution:
+Although by default winapi functions work only with paths up to MAX_PATH, their unicode versions can work with much longer paths, provided that the paths are prefixed with "\\\\?\\". Functions defined in System.Win32.File module (e.g. moveFileEx) call the unicode versions. Solving the length limitation problem might not be as simple as prefixing all arguments with "\\\\?\\", as it does not work with relative paths. I also do not know the git-annex internals so I have no idea how easy would it be to implement, but maybe it could be an easier way than trying to limit the paths' lengths to fit in the archaic MAX_PATH limit. The MSDN page linked below has some more information.
+
+## Workaround:
+It turns out that Windows 10 supports long paths without the "\\\\?\\" prefix, but this setting is by default turned off. According to [this MSDN page](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85\).aspx#maxpath) one can enable it by setting HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled to 1 or by using the group policy editor (Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths). With default settings I was unable to "git annex get" some files in nested directories (it failed with a MoveFileEx error when moving a file from annex\tmp to annex\objects), but after I enabled the long paths option it worked!
+
+This is more of a workaround than a real solution because it requires modifying a global setting which can affect other applications. I also do not know if it solves all path problems with git-annex, but it worked for me so far. I hope this workaround will help others having similar problems.
diff --git a/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa._comment b/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa._comment
new file mode 100644
index 000000000..c58f63ed5
--- /dev/null
+++ b/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rok"
+ avatar="http://cdn.libravatar.org/avatar/a80e31241cb35a3cf9bf8de34e05fc2d"
+ subject="v6 default behavior"
+ date="2017-03-16T09:24:50Z"
+ content="""
+I'm curious about the choice to change the behavior of critical git commands (such as add) in such a drastic way in V6, i.e. why does \"git add\" no longer add files to the git repo? The default of annex should be exclusive rather than inclusive, I shouldn't need to specify which files to *exclude* from annex, rather the other way around. This is an especially confusing default for code. What is the logic here? 
+"""]]