topic Updates Ran with --process update fail in Fusion Support Forum

Updates Ran with --process update fail

Anonymous — Tue, 01 Oct 2019 16:00:02 GMT

We have a few different labs that run the Fusion 360 software on them. The typical process for updating them has failed ever since the new release, citing a file path that it cannot find. I have tried on multiple computers with different configurations and none have worked. The GUI update process works just fine, it is only the silent update process that fails each time. Unfortunately, I need the silent updates to work if I'm going to be managing 100+ computers with this on them.

The WebDeploy Streamer log file also has the following lines in it:

File "E:\3P\PYTHON\3.7.3\win64\lib\urllib\request.py", line 1451, in file_open
File "E:\3P\PYTHON\3.7.3\win64\lib\urllib\request.py", line 1490, in open_local_file
urllib.error.URLError: <urlopen error [WinError 3] The system cannot find the path specified: 'C:\\\\Users\\10STUD~1\\AppData\\Local\\Temp\\7zSB695.tmp\\_payload\\67316f5e79bc48318aa5f7b6bb58243d\\47458aa04dc04be2a184ca4322d75d74\\full.json'>

Upon looking for that directory, I found that it looks as though the parent directory for the full.json file isn't even being properly extracted during the update, and doesn't exist in that path. I also wasn't sure why the beginning of the path has 'C:\\\\'...

Any guidance on this would be appreciated, as I have labs that are not working properly now.

Re: Updates Ran with --process update fail

Anonymous — Thu, 03 Oct 2019 08:34:54 GMT

I also cannot update using the latest version.

I can install it from scratch by calling the exe from an administrative command prompt but if a previous version is installed and I run the exe using "--process update" (with or without the silent switch) it will fail and give me the file not found error.

Re: Updates Ran with --process update fail

g.rileyARE3U — Thu, 10 Oct 2019 15:03:56 GMT

Thank god someone else is also having this issue! I've been banging my head against this very same issue all day. University admin here with 100+ machines running Fusion 360. I have an automated script that handles the downloading and installation (update) of the installer and this has been working beautifully for the last couple of years until today when I see exactly the same issue. The manual / GUI installer completes but the below does not

"Fusion 360 Admin Install.exe" --quiet --process update

and results in the error:

MainThread - adsk.dls.streamer.process - WARNING :: Exception in Update <urlopen error [WinError 3] The system cannot find the path specified: 'C:\\\\Users\\GRAHAM~1\\AppData\\Local\\Temp\\7zSCAFB.tmp\\_payload\\67316f5e79bc48318aa5f7b6bb58243d\\47458aa04dc04be2a184ca4322d75d74\\full.json'>

Re: Updates Ran with --process update fail

g.rileyARE3U — Thu, 10 Oct 2019 15:17:16 GMT

**Update** Just tried running

"Fusion 360 Admin Install.exe" --quiet

on a machine that needed updating and it completed successfully. This is great but I'm now wondering why I bothered including the --process update in the first place. Need to do a bit more testing....

Re: Updates Ran with --process update fail

Anonymous — Thu, 10 Oct 2019 15:25:15 GMT

"--process update" definitely was (and as far as I am aware, still is) the documented way to update an older version of Fusion 360. When I get a chance I'll try the update without that switch.

Re: Updates Ran with --process update fail

g.rileyARE3U — Thu, 10 Oct 2019 15:41:28 GMT

You're absolutely correct, according to the Lab Install Instructions you should use the --process update switch - which is what I have been doing all this time. I'd just like to understand what the difference is because from what I can see the new version installs over the previous version just fine.

Re: Updates Ran with --process update fail

Anonymous — Fri, 11 Oct 2019 10:31:58 GMT

I've just tested the "update" without the update switch and while you do get the new version, it leaves the old version installed too and updates the launcher to point to the new exe.

The files are located in "C:\Program Files\webdeploy\production" if you want to check yourself. It's a possible workaround but it will break my SCCM detection method in it's current form and I'd rather Autodesk acknowledged the issue and fixed it.