go-update icon indicating copy to clipboard operation
go-update copied to clipboard

old exe not deleted on Windows

Open bgentry opened this issue 12 years ago • 7 comments
trafficstars

I think you mentioned that this was still a problem for you. We've got the same problem in hk at the moment since we can't delete a running executable on Windows.

Just curious how you were planning on solving this one (and if this is the right place for it, or if you consider that ngrok's problem to solve).

bgentry avatar Sep 19 '13 06:09 bgentry

Thanks for opening this. I think it's definitely go-update's problem to solve, and I don't have a clean solution beyond simply running os.Remove(oldBinaryPath) and ignoring "file does not exist" errors before the update happens. This will clean it out on the next update run, which is sub-optimal but I can't think of a better solution. I'm open to suggestions though.

inconshreveable avatar Sep 19 '13 16:09 inconshreveable

That was my first thought as well.

There are some really ugly ways that Windows devs accomplish this: http://www.catch22.net/tuts/self-deleting-executables

One other possibility might be to move the old executable to a temp or trash dir instead of moving it to the same dir.

That being said, unless you're running your exe from somewhere highly visible like the Desktop, it's unlikely that most users would notice / care if the old one was left around. I think the simple approach you mentioned is probably good enough for now.

bgentry avatar Sep 19 '13 17:09 bgentry

Wow, that's quite a list. I agree with you about the options, and I'll add one more suggestion. Windows has an API for making files hidden (via SetFileAttributes). Making the old executable a hidden file means it wouldn't show up somewhere noticeable and you could delete it at the time of next update.

inconshreveable avatar Sep 20 '13 06:09 inconshreveable

Alright, I just pushed a fix that makes sure the file it tries to rename to is always deleted before attempting the move. I'm leaving this issue open though because it would be nice to make the removal cleaner or at least less noticeable (via hidden file).

inconshreveable avatar Sep 22 '13 10:09 inconshreveable

Urgh, didn't want github to auto-close this. The hidden file mechanism is implemented now, which is a little less onerous, but I want to leave this open until such point as a real solution is implemented with one of the mechanisms described in the article.

inconshreveable avatar Apr 26 '14 18:04 inconshreveable

why cant you just name the "old" file like that: .prog-04-04-2018-13-56.old so there is always a "new" old file and you dont have trouble with renaming and so on.

ericrange avatar Apr 04 '18 12:04 ericrange

i solved the problem with:

now := time.Now()
err = update.Apply(resp.Body, update.Options{
	OldSavePath: exPath + "/" + now.Format("20060102150405") + ".old"})

ericrange avatar Apr 04 '18 15:04 ericrange