An update moves the running exe aside to exe.old, and when that name is still
held to exe.old-2, -3 (internal/update/update.go, oldName; two of the Windows
install tests assert .old-2 is where the running exe ended up). IsMagpie stripped
".old" and then ".exe", in that order, which unwraps exe.old but not exe.old-2:
".old" is not a suffix of "magpie.exe.old-2", so nothing came off and the name
matched neither magpie nor dial.
So the Gateway card's "Quit magpie and take over" refused to end the user's own
magpie: quitMagpieOnPort takes the "not-magpie" reason and the window says
"which isn't magpie, so magpie leaves it alone", with no way to end it from
there. startHere reads the same function, so it also misreports a magpie that
took the port back as something else.
The tail is now recognised as the count an update appends. Another program's
own name is still left alone: ".old-2" without a number is not ours, and
"magpie.old-backup" is not an update's.
Unchanged: every name IsMagpie already accepted, and the rule that only magpie's
own programs are ended — nothing else is ever touched.
TestIsMagpie's four new paths fail without the change (magpie.exe.old-2,
magpie.exe.old-3, magpie.old-2, dial.old-4 all read as not magpie) and pass
with it; the two negatives are checked in the same table. go vet ./... and the
builds for darwin, GOOS=linux and GOOS=windows pass, and internal/proc passes
-race -count=20.
TryWorld
3cc017cd11