#36 installation issue windows64

set.global was not working, while gin.shell was.

We are redoing the whole setup, extracting the zip (64 version) in the program files folder, unzipping takes forever (>10 min) ??

Then the set.global open the attached window, says everything is fine. Window name says "32" ...

trying to install the 32bit version: also not working.

Interesting. Can you show me what echo %path% shows after the second screenshot?

Hi, not sure if I understood it correctly but when I press any key, it closes the window (the second printscreen) and I open up the command prompt again (where gin again isn't recognized...)

Hi, not sure if I understood it correctly but when I press any key, it closes the window (the second printscreen)

Right, that part is okay.

and I open up the command prompt again (where gin again isn't recognized...)

Can you run echo %path% in the new command prompt and tell me what it shows?

Thanks

It's quite long but here it is...

C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\MATLAB\R2019a\runtime\win64;C:\Program Files\MATLAB\R2019a\bin;C:\Program Files\MATLAB\R2019a\polyspace\bin;C:\Program Files\OpenVPN\bin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\MATLAB\R2019a\runtime\win64;C:\Program Files\MATLAB\R2019a\bin;C:\Program Files\MATLAB\R2019a\polyspace\bin;C:\Program Files\OpenVPN\bin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\MATLAB\R2019a\runtime\win64;C:\Program Files\MATLAB\R2019a\bin;C:\Program Files\MATLAB\R2019a\polyspace\bin;C:\Program Files\OpenVPN\bin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Program Files (x86)\Intel\Intel(R) Management Engine C

I opened the from the gin shell which works fine, and tried to upload some files, where 50% failed to upload. I tried again but it also failed... Not sure if it's related...

Here's a screenshot

The issue with the path seems to be that Windows has a limit on the length of characters in the %path% variable, which defines where executables can be found in the shell. I hadn't anticipated this and I suppose it makes sense that the limit can be reached when a lot of software is installed. I'll have to look into this a bit to see what the best solution might be.

I think the commit/upload issue is unrelated, but I'm not sure. It's possible it might be an issue with the programs available in the global path.

Can you send me the log file? You find it at c:\users\sara-larkumlab\appdata\local\g-node\gin\gin.log and send it to koutsou@g-node.org

Thanks for the log. Unfortunately it wasn't very informative. I'd like you try running the underlying git annex command though gin, which should show the full output without GIN obscuring anything:

gin annex add -c annex.largefiles="((largerthan=10M) and (exclude=config.yml))" .

This should clearly print out any errors that occur during add.

EDIT: Mind the quotes around the value at annex.largefiles="..."

Some (maybe limited) solutions may exist on Windows 10.

@Moberg currently what I can think of is to refer to some components (e.g. Matlab-related paths) in %PATH% as another environment variable. Please refer to this post:

https://stackoverflow.com/questions/34491244/environment-variable-is-too-large-on-windows-10

@achilleas, can gin-cli be set up without changing system path as suggested in the comment: https://docs.microsoft.com/en-us/windows/win32/shell/app-registration?

Keisuke suggested the upload could also be linked to the file path being too long (for any reason, it does not show up here), is it possible?

For upload/download (it would be a different issue), file-path issues would not be the case for 64-bit version of Gin.

Can the default OpenSSH installation somehow conflicts with the SSH in the Gin bundle? What if the Gin-paths get prepended the original %PATH% variable?

@achilleas, can gin-cli be set up without changing system path as suggested in the comment: https://docs.microsoft.com/en-us/windows/win32/shell/app-registration?

Thanks for this. Yes, I think that would be a good idea.

Can the default OpenSSH installation somehow conflicts with the SSH in the Gin bundle? What if the Gin-paths get prepended the original %PATH% variable?

I considered it at first but I didn't want to be greedy and put the GIN stuff higher, though I can see how that would cause issues. I think if I add the paths to the registry based on Julien's link it should be cleaner.

We had a call with Keisuke another one of your colleagues and figured out the issue with the path. The problem was with a system-wide OpenSSH which was older and ahead of gin-cli in the %PATH%, so it took precedence, but was too old to work with our git and git-annex.