Windows binary MODULE_NOT_FOUND

See dungeon-revealer/dungeon-revealer#1545.

Windows is periodically deleting individual files from the temporary directory that the caxa binary is extracted into. This means that the extracted node binary tries to run in a broken project directory which throws MODULE_NOT_FOUND errors. The current workaround for our project is to delete the caxa temporary directory and rerun the initial extraction. This only works for us because we don’t store the user data in the caxa temporary directory.

Example error:

D:\DnD\Dungeon Revealer>"D:\DnD\Dungeon Revealer\dungeon-revealer-windows.exe"
node:internal/modules/cjs/loader:930
  throw err;
  ^

Error: Cannot find module 'C:\Users\SCrid\AppData\Local\Temp\caxa\applications\dungeon-revealer-windows\3bn3q6shhl\0\server-build\index.js'
←[90m    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:927:15)←[39m
←[90m    at Function.Module._load (node:internal/modules/cjs/loader:772:27)←[39m
←[90m    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:79:12)←[39m
←[90m    at node:internal/main/run_main_module:17:47←[39m {
  code: ←[32m'MODULE_NOT_FOUND'←[39m,
  requireStack: []
}

[gkinsman]

Hi there! I just came across this problem in a project. Is there a way to run a script to clean the temp folder before unpacking? I’d like to keep the single executable deploy if possible, but it looks like the temp folder isn’t a very safe place!

For some extra data:

• Running an executable from different locations yields different temp folders.
• After a reboot, each of them stopped working, with different missing files.

Would a more appropriate default be a subfolder in %APPDATA% or %LOCALAPPDATA%? e.g. C:\Users\george\AppData\Roaming\MyElectronApp or C:\Users\george\AppData\Local\MyElectronApp Then it would be untouched by any cleanup process.

[leafac]

Hi @maxb2,

Great to have another detailed report from you.

This is a rather annoying issue. It seems like temporary directories can’t be trusted.

I don’t think we have any control over the settings mentioned by @n1ru4l, so I think that the solution may be https://github.com/leafac/caxa/issues/20. This is unfortunate, because then the user is responsible for cleaning the caxa directory as stuff accumulates in there.

This only works for us because we don’t store the user data in the caxa temporary directory.

Storing application data on the caxa temporary directory would be discouraged in any platform. Even if the operating system isn’t cleaning the temporary directory during execution, it will on reboot.