Self-update on windows

[mzji]

Basically there are 2 strategies: If found a new version of cargo-update, then the program could: 1) Start a cargo install cargo-update --force, and exit 2) Use the method described in this SO thread: Strategies For Replacing Program Executable in Windows

Don't know which one is better and/or easier to implement and maintain, just FYI. Edit: The first one have a timing issue (cargo-update must exit before the new command starts), so the second one is better.

[nabijaczleweli]

Good to know, will read up on that, cheers

[mzji]

Another reference: Self-deleting Executables

[nabijaczleweli]

I failed to make a cmd process that hangs around after the main exec dies so that's POC for now

[mzji]

@nabijaczleweli I'm thinking to write a Windows-only method to do self-deleting Gist will be here later

[nabijaczleweli]

In the last resource you linked there's a mention of MoveFileEx() with MOVEFILE_DELAY_UNTIL_REBOOT, that sounds pretty ideal

[mzji]

@nabijaczleweli That won't help users which don't reboot frequently

[nabijaczleweli]

I envisioned it as first moving it so the update will succeed then marking the moved (still running, but useless after it dies) exec as to delete at shutdown. That way the user will have the updated version straight away and the old one (now renamed to sth like cargo-install-update.exe-v0.3.0) will silently stop existing at shutdown when it's no longer used.

[mzji]

@nabijaczleweli The gist here is a piece of pseudo-code to implement the self-deleting Edit: The delete-after-reboot method won't work if the old exe still exists and another new version of cargo-update is installed without reboot. It will work, however leaving some unused binaries is not good experience for users.

[mzji]

How about this: when user checks update, cargo-update deletes old junks.

[nabijaczleweli]

That's even less ideal tbh because you delay the delete until the next time the user checks for updates instead of next shutdown (also you risk false positives)

[mzji]

But my method means there will be at most 1 old version living with the newest version. And if user checks update multiple times between 2 reboots (which is more common, IMHO), the old version will be deleted silently. Or you could implement both delete-after-reboot and delete-before-update. I don't sure I get the meaning of "false positives", could you provide more details? Thanks! Side note: If Windows cannot find the files which are marked as "delete after reboot", then it will ignore them silently. PS: Maybe you could move the old executable to the Windows temporary directory, then when users clear their harddisk, the old version(s) will be deleted.

[nabijaczleweli]

Now old versions are removed at start, thanks for the suggestion

[nabijaczleweli]

Released in v0.4.1

[mzji]

Yay!