From a7759f089871d2a9e5519622b1d2706b867ab92a Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Wed, 15 Mar 2017 23:55:05 +0000 Subject: [PATCH 1/5] --- ...ed_with_password-based_authentication.mdwn | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn 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 0000000000..323afe23e0 --- /dev/null +++ b/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn @@ -0,0 +1,34 @@ +### Please describe the problem. + + +### What steps will reproduce the problem? + + +### What version of git-annex are you using? On what operating system? + + +### 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 and demand password once + + +[[!meta author=yoh]] From 1bdc63124fc4e67bf89fbc68c7f30903237e3301 Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Thu, 16 Mar 2017 00:01:25 +0000 Subject: [PATCH 2/5] tuned up rushed report --- ..._cannot_be_used_with_password-based_authentication.mdwn | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) 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 index 323afe23e0..852a6045c4 100644 --- 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 @@ -1,11 +1,16 @@ ### 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. @@ -28,7 +33,7 @@ yohtest@rolando.cns's password: yohtest@rolando.cns's password: yohtest@rolando. """]] -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 and demand password once +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]] From 19b6e333af327d103d076900cafd8678b8cafe33 Mon Sep 17 00:00:00 2001 From: "kubaello@d561f15ff5c07a78b706b096375cd89d6d706066" Date: Thu, 16 Mar 2017 01:00:55 +0000 Subject: [PATCH 3/5] --- doc/forum/long_paths_on_windows_10_-_workaround.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/forum/long_paths_on_windows_10_-_workaround.mdwn 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 0000000000..b51bcac5ce --- /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. From 30d1e5b86141afe3cb77badab1bf63ada9a63c59 Mon Sep 17 00:00:00 2001 From: "kubaello@d561f15ff5c07a78b706b096375cd89d6d706066" Date: Thu, 16 Mar 2017 01:22:44 +0000 Subject: [PATCH 4/5] Added a comment --- .../comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment 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 0000000000..7ba0734027 --- /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. +"""]] From 9cef6529cd16530b95b07e328fabb74d5eda79f5 Mon Sep 17 00:00:00 2001 From: rok Date: Thu, 16 Mar 2017 09:24:51 +0000 Subject: [PATCH 5/5] Added a comment: v6 default behavior --- .../comment_1_85fb435417aea2763f9e6631680bd5fa._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa._comment diff --git a/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa._comment b/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa._comment new file mode 100644 index 0000000000..c58f63ed54 --- /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? +"""]]