-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failure to clone on Windows - slow file system? #337
Comments
It does not look like a permission issue on first sight (I tried equipping the |
ah, sorry, no. The failure to remove is a fluke. It happens somewhere inside, the error is simply a vial attempt to clean up after the CTRL-C crash. |
installing 7zip did also not help (though I suspect it is required eventually) |
chatter at initremote stalls at credential retrieval
|
ok, giving up for now. My current suspicion is the credential handling. I get a step further if I add ```credential=data-beta-fzj`` to init remote or the datalad-annex url. Whether its a fix I don't yet know - despite providing the correct token to datalad credentials, init remote throws an authentication failure.
datalad clone probably swallows the auth failure?
|
well, still not the end of the story... setting the token by hand works!!! -.- Which makes git annex initremote succeed:
and also datalad clone!
However (!) the clone call succeeds afterwards even without the credential in the URL ?
|
This is not the end of the issue, I still haven't understood what exactly is going on. What I know is that the init remote call needs authentication, and that on a (Windows?) system that hasn't interacted with Dataverse yet this does not work. There is an interaction with the credential handling - maybe its an issue of interactive prompts that fail, a faulty/missing credential manager underneath, ...?. For added fun, copy-pasting into a password prompt of datalad credentials in Windows CMD inserts some crap that makes the password invalid. Typing the token is not fun. The workaround to the issue is to explicitly set a credential before hand (and by hand) , and then append it to the URL that is cloned from. |
I don't know the involved special remote, but it could be that, on one of the previous attempts, git-annex caches the credentials in its own way, i.e. in |
I tried the JülichData tutorial on Windows, and found that the cloning of the example dataset was seemingly stuck. A possible hint was visible when I
git clone
'ed and interrupted the hanging process:I'm investigating why the deletion failed. It could be that some process still has the directory or that Windows is so slow that it thinks thats the case, or maybe a permission issue...
The text was updated successfully, but these errors were encountered: