-
Notifications
You must be signed in to change notification settings - Fork 110
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
clone from RIA store (kinda) fails with invalid TMPDIR #6514
Comments
I would not rely on a system/setup which "seemingly works" with an incorrect setting of |
It is a user-error, but it's unclear to the user what happened (we actually installed the subdataset despite the command failing) and what didn't (setting up a potential ORA remote properly). |
as outlined in a comment by @bpoldrack in the code, git config -f - can read from stdin. This is supported by git as its a unix convention. Trial and error confirms that this also runs successfully in a Windows CMD. By switching to a git config call with stdin as the input file, we spare the need to write a temporary config file. This fix could thus fix datalad#6514, where a user error lead to a non-existent TMP path and a subsequent failure to create the temporary config file.
as outlined in a comment by @bpoldrack in the code, git config -f - can read from stdin. This is supported by git as its a unix convention. Trial and error confirms that this also runs successfully in a Windows CMD. By switching to a git config call with stdin as the input file, we spare the need to write a temporary config file. This fix could thus fix datalad#6514, where a user error lead to a non-existent TMP path and a subsequent failure to create the temporary config file.
Issue fixed in |
A user reported an issue where she wouldn't be able to
get
a subdataset resulting in:Turns out she had an invalid
TMPDIR=/tmpstore
. The call succeeded on second try, though and it looked like it would behave differently when called with DEBUG logging.Culprit is:
clone
is putting the content of the store'sconfig
into a tempfile in order to let a call togit config
parse it. This is happening post-clone, so the actual cloning has already succeeded, explaining the observed differences in behavior. However, this partial success is not recognizeable to the user.Moreover, the need for the tempfile is questionable to begin with, as this comment in the code states:
So, two things need to be done, from my POV:
Make sure we don't crash in a postclone routine, obfuscating the fact that we already succeeded with the cloning (or crash but then clean up the clone)
As the comment says: If we can confirm this to work reliably, we should switch and not bother with a tempfile at all.
The text was updated successfully, but these errors were encountered: