fix(windows bun upgrade): skip cleaning up old binary
#9696
Conversation
|
❌ @paperdave 2 files with test failures on linux-x64-baseline: |
|
❌ @paperdave 4 files with test failures on linux-x64: |
❌🪟 @paperdave, there are 12 test regressions on Windows x86_64
|
|
❌ @paperdave 6 files with test failures on bun-darwin-aarch64:
|
|
❌ @paperdave 8 files with test failures on bun-darwin-x64:
|
| // We should remove it, however we cannot remove an exe that is still running. | ||
| // A prior approach was to spawn a subprocess to remove the file, but that | ||
| // would open a terminal window, which steals user focus (even if minimized). | ||
| _ = to_remove; |
There was a problem hiding this comment.
If we can't remove it can we move it (rename it). If we can rename it then we can on future runs detected the renamed file <oldfilename>_deleteme and then remove it.
There was a problem hiding this comment.
It turns out you can rename a running executable. We could follow a strategy as described here
There was a problem hiding this comment.
I specifically want to avoid checking for an old exe on every startup of bun.exe. I am already following those instructions except for the last one.
There was a problem hiding this comment.
It turns out you can rename a running executable.
Awww Yiss! From my Windows days I remember hacking around with renaming when it wouldn't let me delete.
Instead of checking for an old version on startup it can be done on the next upgrade call. If it's just a periodic cleanup.
There was a problem hiding this comment.
on the next upgrade call
sure, however i don't see too much use here, as the bun.exe.outdated file will simply be re-ovewritten. deleting it only really does something in the case you do bun upgrade twice in a row.
There was a problem hiding this comment.
True. There may be other lazy opportunities to perform cleanup. There could even be a once very so many executions try to cleanup or after running for so long try to cleanup (just so it stays out of the hot path).
|
im going to merge this in interest in having it ready for 1.1. while leaving some data on disk isn't perfectly ideal, it is better than the status quo. and again i don't feel like this is particularly bad considering other software has taken this route. |
replacing the binary using
bun upgradeis problematic, as you cannot delete a binary that is currently running.my previous solution used a subprocess that outlived the upgrader, but the only way to do this on windows will create a console window for the process. "okay sure, it will flicker in the taskbar but all is fine", i thought.
it seems this window steals user focus for some reason:
and
yikes. i'm going to remove this behavior for now and if this problem can be solved then we can do so later. the new behavior is equal to what some other software does, for example
deno upgrade.