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.
Guess: 7z.exe is on some kind of black list.
Any hints, anyone?
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.
Thanks. I merely wanted to ask if anyone else has bumped into this - and maybe knows a solution.
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.
@Paul_Soderlind Any luck figuring this out (possibly with your IT department)?
I also just received a fancy new (heavily administered) laptop, and I’m having the same IOError as you received. Thanks!
Is there any chance that the heavily adminiswtered laptop allows for WSL2? Basically, we need some kind of trusted sandbox.
Well, eventually the IT folks made an exception for Julia. (Now, please don’t ask me to tell you how I made that happen…)
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
Not the nicest solution, but it did the trick.
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.
Just replaced them. Running the included 7z.exe gave an error message saying it was blocked. Maybe this is not the case for you.
The error code I got was EACCES, not ENOTSUP
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.