Client: windows updater leaves a 31MB *.msi file in the %APPDATA% folder

[jnweiger]

@dschmidt suggests to add a Remove-Item filename to the end of the powershell script to fix this

[guruz]

Hm, didn't the updater(.cpp) code have functionality somewhere to remove the downloaded update after success?

[dschmidt]

Here afaict https://github.com/owncloud/client/blob/master/src/gui/updater/ocupdater.cpp#L409

[dschmidt]

I just confirmed the .msi file is removed as soon as the updater finds "autoUpdateAttempted" set to "true" in the config file on startup in the regular case.
The config file contains the full path (even if it was in %LocalAppData% and would be saved to %AppData% now it should be correctly deleted.

Testing the updater is very tricky. You need to make sure that you have at least two builds with different versions and make sure that the (fake) update server correctly returns the version for the installer otherwise the updater will think that the update failed. Also it's hard to debug because you can't get logfiles from the freshly launched (after update) client without modifying its code.

Is there a config setting for specifying the logfile/logdir? Would you be opposed to adding one?

The only way I can confirm we keep leftover msi files is if the updater downloads additional files before the first one was installed. Maybe we could move all downloads to a subdir in %AppData%\ownCloud which we can wipe after attempted installations or before new downloads (or simply removing *.exe and *.msi).

What do you think?

[dschmidt]

That does not handle the case that something was leftover in %LocalAppData%.
We could maybe delete the old file as soon as we start a new download - that would probably be the easiest.

[jnweiger]

tested under win10

updated 2.4.3 exe to 2.5.0 exe to 2.5.0 msi to 2.5.1rc2 msi

no leftover *.msi files were found, neither under %appdata% nor under %localappdata% -> OK
explorer tempstate folder is also clean after a reboot -> OK
PASS