I’m trying to get Kaju working on some Windows 10 machines I administer remotely. I say I “administer” the machines, but I do not have Admin privileges. The target app is on the user desktop or C:Program Data.
Kaju successfully downloads and decompresses the update, and also successfully copies all items to the backup folder.
In copying from decompressed to the target folder, however, I’ve seen two different errors during different runs:
- “File creation error - The requested operation cannot be performed on a file with a user-mapped section open.” when trying to copy cef.pak, and
- “Sharing violation” on trying to copy icudt65.dll after having successfully copied eight other items, including cef.pak.
After one of these errors occurs, Kaju’s log reports “… confirmed”, then “Removing backup…”
Next, Kaju attempts to copy the backup exe file from the backup folder to the target folder, and always logs “Access is denied”. The Kaju log then reports “…removed” (which is not true), and goes on to remove the decompressed folder.
The shell script puts up a dialog saying it can’t find the target exe, because of course it wasn’t copied.
I can, as a non-Admin user, go in and manually copy the backup exe to the target folder without any problem or UAC dialogs popping up, so I don’t know why the script fails with “access denied”. That aside, the real problem I think is the previous errors in copying the new files to the target folder. The final state of the app is that all of the backup files have been copied back into the target except for the exe (which is still in the backup folder).
On my own machine (which I do have Admin privileges on, FWIW) everything works.
The variability of the copy errors leads me to wonder if it could possibly be a timing issue. Watching the process, I see the terminal window open well before my app’s windows have closed in the background (the target machines are slow, and my own test machine is faster). Maybe the app hasn’t fully quit by the time the shell script is trying to move stuff around? Seems weird, considering that the shell is (as I understand it) fired by the Kaju Initiater being nilled in the app’s Close event.
Looks like it in fact takes about 10 seconds for the app windows to go away, but I’ll probably leave it at “ridiculously long” as I intend updates to happen silently in the dead of night without operator intervention anyway.