This issue is directly related to issue #1514 . Not sure why this was closed before verifying that it worked, because, when I initiated the auto update to ipfs-desktop 12.0, the exact same issue occurred once again. Program was uninstalled, not re-installed, and the installation files were located in the %USERPROFILE%\Appdata\local\ipfs-desktop-updater. I did notice that there were 2 executable files in the directory though (I don't recall if there were last time): one named "updater.exe" and one that was the actual install file for the program (IPFS-Desktop-Setup-0.12.0.exe). Interestingly, while both were the same size, (83,195 kb), I noticed that the hash values were different, so they are not the same file? I don't know. What I do know is that the process is still broken and the potential cause of the issue which I mentioned in the 2nd of the 2 potential causes I listed remains unchanged (update-info.json "isAdminRightsRequired" value is still euqal to false, and as I stated the first time, you need admin permissions to install an application to the program files directory, which is where ipfs desktop is installed when you install it for all users). Maybe I am an outlier in this mindset, but I am of the belief that issues should be confirmed resolved before closing them.Auto update not working on Windows when installed globally for all users
Describe the bug
I have noticed that, the last two times that IPFS-desktop has updated using the internal update functionality (when the app says a new version is available and to click button to close IPFS-desktop and install the updated version), the old version of ipfs-desktop successfully uninstalls the old version, but does not install the new version correctly. I should note that I install IPFS-desktop so that it available for all users, not just the currently running user, which I think is the main reason the auto-update might be failing. There are a few reasons that I can think of that might be the cause:

To Reproduce
Steps to reproduce the behavior:
Expected behavior
IPFS auto-update functionality would automatically re-install the application successfully with the same configurations as the previous install
CC @rafaelramalho19 -- thank you!
@demdante Thank you for the detailed and long description of the issue. However, the fix that we actually shipped will only be executed in the next version update.
What happened is that your current auto-update was performed with the code from v0.11.4, not with the one from v0.12.1. Therefore, this fix will only be visible from this version onwards.
Sorry if I didn't give this explanation before. I'll let the issue open until we have a new version of desktop.
We appreciate your feedback, thank you 🙏
@rafaelramalho19 I just want to make sure I understand this correctly, as well as offer a correction to my original statement. The correction being that the issue is not exactly the same as it was before: it is worse now. I initially had installed version 0.12.0 on my machine, and when I initiated the auto-update to update to version 0.12.1, but now nothing at all happens: IPFS-desktop closes, but unlike before, it doesn't even uninstall successfully now, much less re-install the most up-to-date version. The fact that the auto-update behavior has changed, in addition to the fact that, based on the activity in the now closed, original issue that I opened, the pull request which was meant to resolve this issue was merged and implemented 12 days ago (and two versions have been released since then) leads me to believe that the fix meant to resolve the issue was actually implemented in version 0.12.0 as well, and, if that is the case, then, unfortunately, this is still an issue, but even more so now. In fact, I can absolutely guarantee that the issue is still occurring, by simply looking at the differences between the master branch the version 0.12.0 release: the only difference being what you see below, which has nothing to do with the auto-update feature:

When the auto-update process initiates in version 0.12.0 when upgrading to version 0.12.1, I can go and re-open the application, and it will continue to try and fail to even uninstall the old version now. Here are entries from the combine.log which show the last few times this has happened:
2020-07-07T23:38:22.114Z info: [web ui] window ready
2020-07-07T23:38:22.115Z info: [tray] starting
2020-07-07T23:38:22.248Z info: [tray] started
2020-07-07T23:38:22.248Z info: [ipfsd] start daemon STARTED
2020-07-07T23:38:27.570Z info: [daemon] PeerID is QmNjQdw8h3pxoZ5oWPYzeKZkWgFze6hRghGCmRMt1FdPBn
2020-07-07T23:38:27.570Z info: [daemon] Repo is at C:\Users\john\.ipfs
2020-07-07T23:38:27.571Z info: [ipfsd] start daemon FINISHED 5.321959401s
2020-07-07T23:38:29.454Z info: [updater] update available, download will start
2020-07-07T23:38:29.459Z info: [ipfs on path] no action taken
2020-07-07T23:38:29.459Z info: [launch on startup] disabled
2020-07-07T23:38:29.665Z info: [updater] update downloaded
2020-07-07T23:38:34.963Z info: [ipfsd] stop daemon STARTED
2020-07-07T23:38:35.031Z info: [ipfsd] stop daemon FINISHED 0.06729930000001332s
2020-07-07T23:38:35.068Z info: [quit-and-install] stopIpfs had finished with status: 5
2020-07-08T02:29:06.316Z info: [meta] logs can be found on C:\Users\john\AppData\Roaming\IPFS Desktop
2020-07-08T02:29:07.275Z info: [web ui] window ready
2020-07-08T02:29:07.276Z info: [tray] starting
2020-07-08T02:29:07.389Z info: [tray] started
2020-07-08T02:29:07.390Z info: [ipfsd] start daemon STARTED
2020-07-08T02:29:12.833Z info: [daemon] PeerID is QmNjQdw8h3pxoZ5oWPYzeKZkWgFze6hRghGCmRMt1FdPBn
2020-07-08T02:29:12.833Z info: [daemon] Repo is at C:\Users\john\.ipfs
2020-07-08T02:29:12.834Z info: [ipfsd] start daemon FINISHED 5.443837898999453s
2020-07-08T02:29:14.650Z info: [updater] update available, download will start
2020-07-08T02:29:14.655Z info: [ipfs on path] no action taken
2020-07-08T02:29:14.655Z info: [launch on startup] disabled
2020-07-08T02:29:14.855Z info: [updater] update downloaded
2020-07-08T02:29:18.715Z info: [ipfsd] stop daemon STARTED
2020-07-08T02:29:18.782Z info: [ipfsd] stop daemon FINISHED 0.06644140000082552s
2020-07-08T02:29:18.817Z info: [quit-and-install] stopIpfs had finished with status: 5
2020-07-08T02:43:18.406Z info: [meta] logs can be found on C:\Users\john\AppData\Roaming\IPFS Desktop
2020-07-08T02:43:19.373Z info: [web ui] window ready
2020-07-08T02:43:19.374Z info: [tray] starting
2020-07-08T02:43:19.488Z info: [tray] started
2020-07-08T02:43:19.489Z info: [ipfsd] start daemon STARTED
2020-07-08T02:43:24.317Z info: [daemon] PeerID is QmNjQdw8h3pxoZ5oWPYzeKZkWgFze6hRghGCmRMt1FdPBn
2020-07-08T02:43:24.317Z info: [daemon] Repo is at C:\Users\john\.ipfs
2020-07-08T02:43:24.318Z info: [ipfsd] start daemon FINISHED 4.828577800000087s
2020-07-08T02:43:26.216Z info: [updater] update available, download will start
2020-07-08T02:43:26.220Z info: [ipfs on path] no action taken
2020-07-08T02:43:26.220Z info: [launch on startup] disabled
2020-07-08T02:43:26.431Z info: [updater] update downloaded
The lines that I think are most relevant are the ones that state "[quit-and-install] stopIpfs had finished with status: 5" and then the lines immediately following showing me starting ipfs-desktop again. So, yeah, this still seems to be an issue.
@demdante The version 0.12.0 was broken because the build used for the deployment was actually the same as 0.11.4 (weird pipeline bug that happened once before). Therefore, if you actually open the ipfs-desktop application on that version, you'll see that go-ipfs is still using 0.5.1, while if you open in 0.12.1 you'll see that it uses 0.6.1
If this happens again while upgrading to 0.12.2/0.13.0, please tell us so we can look more into this.
Dear @rafaelramalho19 and @demdante
This bug is also present in the lastest ipfs version available for download: 0.14.1
When installed for all users (with admin permisions), the application says it will upload the last version, downloads the update from the internet into%userprofile%\AppData\Local\ipfs-desktop-updater the installer of 0.14.1 and it empty all the contents of C:\Program Files\IPFS Desktop leaving the non working shotcuts on the desktop
I am using Windows 10 64 bits
Dear @demdante please look into the issue since is afecting all the new windows users of IPFS Desktop that choose this popular option.
Thanks in advance,
Pedro
@demdante we just released a new version of desktop. Can you confirm this issue is fixed?
This is the explanation why I have been stuck many days with this loop.
I have installed IPFS Desktop just for my user (not for all users) Using the link still on the README (for v0.11.4).
The IPFS Destkop App for Windows asks me to restart it every time I start it. Clicking on "restart" will close the application. Starting the application again will eventually lead to the same screen:


There is a workaround - changing the 'false' to 'true' in %USERNAME%\appdata\local\ipfs-desktop-updater\pending and then running the 0.12 installer manually. At least, this worked for me.
I also had the same issue on and off for the past several weeks.
It works now. But that happened before and then the issue reoccurred.
The number of peers are growing, steadily The highest I seen so far was 262.
Rely on it, and build around it.

Let's hope this issue won't come back.
Thank You
It seems https://github.com/ipfs-shipyard/ipfs-desktop/pull/1556 does not work as expected (or there is a new regression in electron-builder).
@rafaelramalho19 I think the issue is still present. Are able to confirm?
I got the update error no matter if I install for a single user or all users.
Quick note: auto-update from 0.12.2 to 0.13 functions as expected on Mac.
Update destroyed IPFS Desktop again.
Windows 10
See https://github.com/ipfs-shipyard/ipfs-desktop/issues/1680 from @gyuri-lajos with error info.
Confirmed this is a regression limited to Windows and autoupdate orchestration provided by electron-builder.
We are working on a fix in https://github.com/ipfs-shipyard/ipfs-desktop/pull/1679.