On 7/9/25 20:31, Bruce Horrocks wrote: [...]

...

Otherwise I would look at the permissions of the binary (i.e. whatever `context` resolves to when it is run on Windows).

This is also my guess. Permissions seems to be the same (although not checked with `icacls`, just `ls -lh` with MSYS2 and visual comparison in the security

On 7/9/25 21:11, Pablo Rodriguez via ntg-context wrote: properties tab), but there seems to be something in the binaries themselves. BTW, trying to perform another check, I just copied `$HOME/context` (updated to current latest) to `$HOME/context-win64` and there I run `./install.sh --platform=win64`. It seems to work fine, except for `mtxrun.exe` (which isn’t downloaded to `bin/` or to `tex/texmf-win64/bin`). I wonder whether this is intended. Pablo

On 7/10/25 22:37, Bruce Horrocks wrote:

On 10 Jul 2025, at 15:25, Pablo Rodriguez via ntg-context wrote:>>

...

It seems to work fine, except for `mtxrun.exe` (which isn’t downloaded to `bin/` or to `tex/texmf-win64/bin`).

mtxrun.exe comes from the .zip file you download from the installers page on the Contextgarden website. Many thanks for your help, Bruce.

I knew, but I was downloading a Win64 distribution (with its binaries) on a Linux64 OS (afaIk, `$HOME` is a Unix variable, `%USERPROFILE%` in Windows). This was the reason why I invoked `./install.sh --platform=win64`. Two minutes after sending my message, I downloaded it from http://lmtx.pragma-ade.nl/install-lmtx/context-win64.zip. Installation went fine (my Linux64 box doesn’t complain for Win64 binaries, since I don’t run them there). On my Win64 at work, `mtxrun --generated` gives the already referred message "Access denied" (well, in Spanish).

If that doesn't show anything unusual then try the icacls command. I got the following output:> c:\context\bin>icacls mtxrun.exe mtxrun.exe BUILTIN\Administrators:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Users:(I)(RX) NT AUTHORITY\Authenticated Users:(I)(M)

Successfully processed 1 files; Failed processing 0 files

I get the same output for both not working newest lates and working previous latest (but in Spanish): C:>icacls "c:\new\tex\texmf-win64\bin\mtxrun.exe" c:\new\tex\texmf-win64\bin\mtxrun.exe BUILTIN\Administradores:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Usuarios:(I)(RX) NT AUTHORITY\Usuarios autentificados:(I)(M) Se procesaron correctamente 1 archivos; error al procesar 0 archivos C:\Desktop>icacls "c:\old\tex\texmf-win64\bin\mtxrun.exe" c:\old\tex\texmf-win64\bin\mtxrun.exe BUILTIN\Administradores:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Usuarios:(I)(RX) NT AUTHORITY\Usuarios autentificados:(I)(M) Se procesaron correctamente 1 archivos; error al procesar 0 archivos

Try the above first and we can troubleshoot a bit more if the cause still isn't clear. To confirm that I speak of the same binaries (old and new) as you:

$ sha512sum /c/new/tex/texmf-win64/bin/*.exe 831e6fdd20ef32c5d8397c6eaa43c6fcf824c4f05720eb0ef9ec40c240de74b33c388d77af06fe59b24f5b548c9a9454a10cbcf0b5c55f5767866c7c99eb016e */c/new/tex/texmf-win64/bin/context.exe 831e6fdd20ef32c5d8397c6eaa43c6fcf824c4f05720eb0ef9ec40c240de74b33c388d77af06fe59b24f5b548c9a9454a10cbcf0b5c55f5767866c7c99eb016e */c/new/tex/texmf-win64/bin/luametatex.exe e156a063e5459a9ad9840d816ba69f9edfc448e71fda15b7d0f392cc9bfd4972e56584f2e874d67ffdf12787c969ae3cbdf5c73554cb1dff8edba518ebb50d81 */c/new/tex/texmf-win64/bin/luatex.exe 831e6fdd20ef32c5d8397c6eaa43c6fcf824c4f05720eb0ef9ec40c240de74b33c388d77af06fe59b24f5b548c9a9454a10cbcf0b5c55f5767866c7c99eb016e */c/new/tex/texmf-win64/bin/mtxrun.exe $ sha512sum /c/old/tex/texmf-win64/bin/*.exe b18ef7b0b49ea6423920b1dd50aaa643ebc984a437acc602e9c949855742e768510cc765e1c3ef75ed18b18279bb996b80ac56d380a65a325d2b6663ff2a9167 */c/old/tex/texmf-win64/bin/context.exe b18ef7b0b49ea6423920b1dd50aaa643ebc984a437acc602e9c949855742e768510cc765e1c3ef75ed18b18279bb996b80ac56d380a65a325d2b6663ff2a9167 */c/old/tex/texmf-win64/bin/luametatex.exe e156a063e5459a9ad9840d816ba69f9edfc448e71fda15b7d0f392cc9bfd4972e56584f2e874d67ffdf12787c969ae3cbdf5c73554cb1dff8edba518ebb50d81 */c/old/tex/texmf-win64/bin/luatex.exe b18ef7b0b49ea6423920b1dd50aaa643ebc984a437acc602e9c949855742e768510cc765e1c3ef75ed18b18279bb996b80ac56d380a65a325d2b6663ff2a9167 */c/old/tex/texmf-win64/bin/mtxrun.exe BTW, this made me realize that `mtxrun`, `context` and `luatematex` are exactly the same binary. Old worked and new didn’t. What worked for me were the 32bit binaries (full install from http://lmtx.pragma-ade.nl/install-lmtx/context-mswin.zip), My Windows installation may be picky with the newest binaries, but I think there may be something with them. Of course, I cannot say what that might be, but something different from previous compiliations. Many thanks for your help, Pablo

On 7/13/2025 12:32 AM, Bruce Horrocks wrote:

Well I did wonder why you were using Unix syntax but saying the problem was with your Windows machine.

makes me wonder if Pablo has the linux subsystem running which indeed can then launch sh scripts (it just start up the installed linux box) and i dont' want to think how that all can then interfere for instance because on unix we make symlinks to mtxrun and context (i use the subsystem for compilation and can run context there without problems but then with linux binaries) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 7/13/25 00:32, Bruce Horrocks wrote:

...

On 11 Jul 2025, at 15:42, Pablo Rodriguez via ntg-context wrote: […] I knew, but I was downloading a Win64 distribution (with its binaries) on a Linux64 OS (afaIk, `$HOME` is a Unix variable, `%USERPROFILE%` in Windows).

Well I did wonder why you were using Unix syntax but saying the problem was with your Windows machine.

Also `$USERPROFILE` is a MSYS2 (https://msys2.org) extended variable to have a Windows variable on a Linux shell (I used it on my first reply to Hans in this thread.)

...

[…] Installation went fine (my Linux64 box doesn’t complain for Win64 binaries, since I don’t run them there).

But installation on which machine? Or do you mean "download" went fine? It's all very confusing.

You’re right, Bruce, it was only donwloading the Win64 distribution with `install.sh` (on a Linux64 machine). This workaround (download a complete Win64 ConTeXt distribution on a Linux64 machine, to use them on Windows) was only an alternative way of testing that my usual update (on Windows) was giving me the right binaries.

[…] Okay, so it looks like the permissions are correct. […] You can calculate checksums directly in Windows, rather than over a file share, by using PowerShell:

Good to know, but MSYS2 is fine for me.

I get the same as you do above for mtxrun.exe. […] That definitely sounds like a problem with your work computer's configuration. If you are running 64-bit Windows then the 64-bit binaries should run just fine.

I have been running both 64bit Windows and 64bit binaries (for ConTeXt) for more than five years. I wonder whether this makes more than one hundred binaries, being the latest one the first and only one that has been denied access by Windows.

What do you get if you run

C:\> where.exe context.exe

It's the equivalent of Unix's 'which' command so will help determine if the .exe being run is the one that you think it is.

Typing from what I got with the Windows computer at work: c:\context\tex\texmf-win64\bin\context.exe I thought `whereis` was the Unix counterpart to `where` (but I got exactly the same result with both, in any case). Since the win32 binaries do work, I have to test newer binaries to check whether my issue is persistent, permanent or it just disappears. Many thanks for your help, Pablo

On 7/14/25 18:02, Hans Hagen via ntg-context wrote:

On 7/14/2025 3:39 PM, Pablo Rodriguez via ntg-context wrote:

...

Good to know, but MSYS2 is fine for me.

i can actually compile luametatex under msys rt (or cygwin but that one i'll remove when i have time) but prefer to use the linux subsystem so actually at the windows end we have native (more secured), cross compiled (faster than native so i use that) and msys (probably a mix)

Sorry, Hans, this was only related to how I get my SHA sums (MSYS2 is more like home field to me than PowerShell). Cross-compilation for ConTeXt binary is totally fine for me (even with this one particular nasty glitch).

...

I wonder whether this makes more than one hundred binaries, being the latest one the first and only one that has been denied access by Windows.

unless you changed your system (like different path added?)

I haven’t changed anything, but not being self-employed and having all IT being remotely managed, I cannot say that I’m 100% sure that no system-related thing has been changed (I’d rather avoid asking about this [too long and rather stupid story]).

afaikt nothing changed in the installer so luametatex should work ok and 64 bin binaries have been around for a while

I have been using most of these binaries for that while, since I tend to update to current latest(*), without any issue (huge thanks for that to everyone involved). (*) I came to realize that I prefer to hit new bugs (that need reporting and fixing) than older ones (that may have been already fixed). In an unexpected twist, testing (about three hours ago) what Bruce asked me to explain, binaries started working again (`context --version` or `luametatex --version` gave the right output instead of the message in Spanish "Acceso denegado"). So it seems that these binaries are usable again (sorry for being overcautious, but I would like to test them extensively [I have used it as in any other previous ConTeXt distribution and they seem to work fine; but the more extensive the testing, the better]). Many thanks for your help and sorry for what turned out to be noise, Pablo

On 7/15/25 00:07, Bruce Horrocks wrote:

...

[…] c:\context\tex\texmf-win64\bin\context.exe

Earlier, when you ran the `icacls` command, you ran it against "c: \new\tex\texmf-win64\bin\mtxrun.exe" and "c:\old\tex\texmf- win64\bin\mtxrun.exe". The output given by the where command is neither of those.

Sorry, Bruce, this has to do with the way I manage different ConTeXt versions in Windows (and in Linux before, but that is irrelevant here). I only have `c:\context\tex\texmf-win64\bin\` added to `%PATH%` (no other ConTeXt-related path is part of `%PATH%`). Experience has taught me to backup previous versions, since I may have issues with newer ones (and after all I’m in production [so to speak]). So I have right now: 1. `c:\context\`. 2. c:\context - copy X\ (where copy is from 1 up to 17). 3. `c:\context-32\`. #3 was only required while my system denied access to current latest win64 binary (SHA512 starting with 831e6fdd20ef3…). This also required an extra `c:\context\tex\texmf-mswin\bin\` added to `%PATH%`. In fact, since latest win64 binaries seem to work on my OS, I have removed `c:\context-32\` (although I keep the extra path untill I update at least one more time without glitches). To change versions, I use the file browser to change the relevant folder name to `context` only. My update procedure (not exactly rocket science, but it just works): 1. Go inside `C:\` with the file browser. 2. Select the `context` folder. 3. Copy and paste it (`Ctrl+c` plus `Ctrl+v` does the job). 4. Add the corresponding number after `context - copy`. 5. Go inside `C:\context\` and double-click on `install.bat`. BTW, to report here, I renamed `c:\context - copy 17\` to `c:\new\` and `c:\context - copy 16` to `c:\old\` to make it easier to fit and clearer to understand. Sorry for the painful verbose explanation, but I hope it is clear now. Attached is the output from MSYS2 terminal (https://www.msys2.org/docs/terminals/#mintty) after I successfully ran both `context --version` and `luametatex --version` (standard messages, no "Acceso denegado" message). Of course, I haven’t changed any ConTeXt-related path starting from the two commands from previous paragraph (this includes all commands in attachment). Sorry for not being completely clear and accurate in my explanations and many thanks for your help, Pablo

On 7/17/25 23:53, Bruce Horrocks wrote:

[...] But I suspect the best way to reset everything in order to start again would be to make a backup by renaming the directory as you currently do and then do a fresh install of the Windows 64-bit version using nothing but Windows command line commands. Don't do anything with MSYS2 until you first have it working in Windows.

Many thanks for your help, Bruce. I think I have solved the issue, but I’m afraid I cannot fix it. Windows 1x has a thing called “Virus and thread protection” (part of “Windows Security”). Anytime I have tried to run latest `context.exe` (64bit only [32bit is still fine]), the thread protection logs a low-risk action blocked. What is that? Well, not being administrator on the OS not even tells which binary caused this (not to mention what the action was). It seems to be caused by a (n unknown to me filtering) rule. Sorry for the noise and wasting your time (both Hans and Bruce), since the root of the problem has always been elsewhere. Many thanks for your patient help, Pablo