Error: spawn toktx EACCESS

[hybridherbst]

Describe the bug
Haven't seen this one before and not sure why it suddenly started happening:

Seems it's trying to spawn "toktx --version" - if I do that right below, it works:

To Reproduce
No idea, but wanted to have this tracked. Currently I can't use gltf-transform for compressing textures due to this issue.

Versions:

• Version: [2.4.7]
• Environment: [CLI]

Additional context
Tried on both Node 16 and 18. 18 always logs an error: fetch failed for any gltf-transform command it seems, even --version, but seems to succeed nonetheless.

[donmccurdy]

On latest Node.js v18.12.1 I'm seeing:

> gltf-transform --help
(node:62303) ExperimentalWarning: The Fetch API is an experimental feature. This
feature could change at any time (Use `node --trace-warnings ...` to show where 
the warning was created)

error: Failed to parse URL from /Users/donmccurdy/Documents/Projects/glTF-Transform/node_modules/@squoosh/lib/build/imagequant_node-a4aafbae.wasm

I believe that part comes back to GoogleChromeLabs/squoosh#1242, squoosh (used for WebP, JPEG, and PNG optimization) needs some updates for Node.js 18.

However, I can't seem to reproduce the "EACCESS" error. If anyone else is seeing that and can suggest ways to debug that would be helpful. I'm wondering if this might be related to a recent Node.js 18 update, and/or Windows OS?

[CodyJasonBennett]

Related: withastro/astro#5051 (comment).

[donmccurdy]

@hybridherbst would you be up for building the library locally and seeing if the EACCESS error re-occurs? I'm wondering if Squoosh is also the cause of that, and whether removing it from the build would fix things. If so it might be time to switch from Squoosh to Sharp (https://sharp.pixelplumbing.com/) or something else.

[donmccurdy]

• cc Replace Squoosh with Sharp for image optimization #751

[donmccurdy]

@hybridherbst could you give this a try on your OS?

npm install --global @gltf-transform/cli@next

It's a prerelease for v3 (with #752), including sharp instead of squoosh.

[hybridherbst]

Don't think it's squoosh-related unfortunately:

To me it looks like for some reason spawning "toktx --version" is failing...

[CodyJasonBennett]

Are there any assets I can use to reproduce this? I want to see if I can get a more helpful stack-trace out of Node.

[hybridherbst]

The problem is that it seems to be machine-related, I'm able to run this on the same asset just fine on other machines, even with the same Node and OS versions. I suspect some kind of permissions issue but haven't seen this happen with another node tool (even ones that also spawn toktx processes) so thought I'd track it here.

The asset I used above is this one: Textures-4k.zip

[donmccurdy]

Ah well.

Does --jobs 1 make any difference here? Possibly concurrency limits ...

[donmccurdy]

Glad to help with this if someone can look into the cause, as I don't have Windows access. PRs also welcome! In the meantime I am assuming it is concurrency-related, and can be avoided by specifying --jobs or node.js environment settings.

[hybridherbst]

Does unfortunately not change it, would be great if you could reopen this issue.

I'm not sure which node.js environment settings I'd need to change or look into – any hints?

[donmccurdy]

I was thinking of limits on the number of open files with Node.js, but now I don't think that matches up with the context or the error message. Maybe more likely some kind of permissions error on the temporary files or folders created by toktx? Not really sure what to make of this. It might be worth trying to manually run the toktx calls emitted with --verbose and see if those paths are valid.

Ideally something like #675 would be a solution, without messing with the filesystem and spawning processes, but I'm not sure what options we really have there.

[donmccurdy]

The only thing I'm aware I can do here is to look for a solution to #675. If someone will continue investigating the EACCES errors, I am happy to reopen this issue.

[hybridherbst]

I have some additional info that I wanted to share, maybe it's helpful in the future:

• the EACCESS errors are only happening when running global gltf-transform from C:/
• they're not happening when running global gltf-transform from any other drive.
  ... independent of the actual folder, just the drive seems to matter.