From 3fc73599fa293c152d62488be7d2e3e697a4bf96 Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Wed, 15 Mar 2017 23:55:05 +0000 Subject: --- ...be_used_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 000000000..323afe23e --- /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]] -- cgit v1.2.3 From 3dbc69108b696909aa12cd69f695aedce8a5c1cd Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Thu, 16 Mar 2017 00:01:25 +0000 Subject: tuned up rushed report --- .../get_-J_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 323afe23e..852a6045c 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]] -- cgit v1.2.3 From 3821e3aa3ba061fdb6ac31964d14a5a8141a2def Mon Sep 17 00:00:00 2001 From: "kubaello@d561f15ff5c07a78b706b096375cd89d6d706066" Date: Thu, 16 Mar 2017 01:00:55 +0000 Subject: --- 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 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. -- cgit v1.2.3 From 00d21b7a5b2f15fee2dc2e8104ba6320e15cfa09 Mon Sep 17 00:00:00 2001 From: "kubaello@d561f15ff5c07a78b706b096375cd89d6d706066" Date: Thu, 16 Mar 2017 01:22:44 +0000 Subject: 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 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. +"""]] -- cgit v1.2.3 From 6507bf52d338edbbe761da4585d7d3d77cbc6cb9 Mon Sep 17 00:00:00 2001 From: rok Date: Thu, 16 Mar 2017 09:24:51 +0000 Subject: Added a comment: v6 default behavior --- doc/upgrades/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 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? +"""]] -- cgit v1.2.3