Open pravic opened 3 years ago
c:\windows is not accessible by default unless you run with administrator privileges.
I assume this is because of simple permission problems. Closing.
c:\windows is not accessible by default unless you run with administrator privileges.
@heinthanth c:\windows isn't accessible for writing by default.
I assume this is because of simple permission problems. Closing.
@dom96 I suspect that choosenim was trying to move (aka rename) the unpacked directory - a quite common pattern to avoid unnecessary copy. But on Windows you can't move a directory to another drive, thus the access error.
Just a speculation but with a good chance of being true. Because c:\windows\temp is accessible for writing by anyone; moreover, choosenim does unpack its archives - it just fails to place them at the desired choosenimDir
after downloading and unpacking.
But on Windows you can't move a directory to another drive, thus the access error.
huh, haven't heard of this before. In any case, would appreciate your help on this one if this is important functionality for you.
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefile
Basically, you can move a file to another drive (it will be a copy of file + delete), but you can't move a directory to another drive - it fails.
choosenim does unpack its archives - it just fails to place them at the desired choosenimDir after downloading and unpacking.
However, I see that you use https://github.com/dom96/choosenim/blob/1e9380741da1062e91fa7900b444211998441599/src/choosenimpkg/utils.nim#L103
So, the problem is somewhere else. I'll try to debug.
Apparently,
choosenim
doesn't like when--choosenimDir
points to another drive if it's different fromTEMP
:On the same drive it's it works fine:
Although it seems that it's a pain anyway to specify a custom directory for
choosenim
andnimble
:choosenim
doesn't store the specified directory and always wants it in a command linenimble
uses its ownnimble.ini
and I have no idea how well it plays withchoosenim
Sigh.