I got a fancy new laptop, heavily administered by the IT dept…
When doing up or even just using VScode, the following error message pops up:
ERROR: IOError: could not spawn setenv(`'C:\Users\XX\AppData\Local\Programs\Julia-1.8\libexec\7z.exe' x 'C:\Users\XX\.julia\registries\General.tar.gz'
...
Solution: run as admin, but that is not very popular with the IT dept.
There isn’t really anything we can say/help to diagnose this - that error can have a multitude of reasons, only one of which is related to permissions. I’d suggest talking to your IT department about what could cause this, if you’re otherwise able to run 7z.exe.
Well one other guess I’d have is that your IT department restricted the directories where .exe can be started from - in which case, the solution would be to ask your IT department to allow the directory where those julia installed binaries are located as well.
I had this problem too. I found that the version of 7z.exe included with Julia is flagged as malware and blocked by Windows Security. Try running it from Explorer and see if you get an error message.
The solution was to replace 7z.exe (and 7z.dll whilst at it) with a newer version (23.01 currently). You can see the path in the error message, for me it was
C:\Users\username\.julia\juliaup\julia-1.9.4+0.x64.w64.mingw32\libexec\julia\7z.exe
Hmmm. Updated those .dll & .exe files doesn’t seem to have fixed the issue for me. Were there any rebuilding steps you had to take as well? Or just replacing the files worked fine?
Unfortunately no WSL allowed. Don’t know if it would help my use case either. I’m using MATDaemon.jl to spin up a julia server in the background of a MATLAB process, and I don’t think that workflow currently supports WSL.
Since this is a known result of Julia trying to run 7z.exe, and a rather cryptic error maybe as a start it could be changed to:
ERROR: IOError: could not run 7z.exe on behalf of Julia, likely because of strict IT dept. blocklisting, please then talk to your administrator about it.
[Spawn was correct, could be kept, setenv part was a bit cryptic and confusing.]
As is people might blame Julia for not working, rather than putting the blame where it belongs, with the above amended error message.
Interesting. That’s something that Julia could do too. I suppose what is being checked for is some checksum of the z7.exe (or its .dll) since you can’t rely on just the name to block (it could be renamed and run), but I suppose a later version will be blocked in later version of that draconian security measure.
I believe Julia also has a decompression capability, built in or in a .dll (independent of that .exe), at least for files, if not full .zip supporting directories.
Maybe Julia could use that instead? But we don’t want to risk just Julia itself being blocked… nor also implement our full 7z.exe clone…
I hope malware will not get started built with Julia, then julia.exe being risked blocked. This would be a potential problem for all languages, e.g. Python too, and compilers that can e.g. build 7z.exe…
It really seems rather arbitrary to stop decompression programs, rather than (e.g. certain .exe) files you get after decompressing a certain file.