Squirrel.windows: My installer doesn't seem to remove old versions...

[JonZso]

Image
Is there a way for me to force the removal of previous versions..?

[Slion]

It should only keep the previous version. Not sure why yours shows so many version.
Though I remember people asking to be able to keep more versions and I think it was being implemented.

[DaneVinson]

Same issue here. Also, the packages sub-folder of the application installation folder is retaining all packages forever.

[DaneVinson]

After a bunch of debugging I've found this issue (at least for my case) is due to the fact that the UnsafeUtility.EnumerateProcesses call in UpdateManager.ApplyReleases cleanDeadVersions method returns Tuples with null Item1. The results of that are saves to the variable runningProcesses an then the following is applied to it runningProcesses.All(p => !p.Item1.StartsWith(x.FullName, StringComparison.OrdinalIgnoreCase)). p.Item1 is null so a NullReferenceException is thrown and the clean-up process terminates. In my case UnsafeUtility.EnumerateProcesses returns 57 of the 138 processes with null Item1.

I'll attempt to create a pull request for this issue.

[anaisbetts]

@DaneVinson Thanks for the debugging and the future PR!

[DaneVinson]

Just out of curiosity how would you feel more comfortable handling this?

My first thought is to set the exception case to String.Empty instead of
default(string) in EnumerateProcesses (Squirrel.Utilty.cs line 819). That
method looks to be called in three locations,
Squirrel.Tests\UtilityTests.cs, SquirrelUpdateManager.ApplyReleases.cs
(where the issue is occurring) and Squirrel\UpdateManager.InstallHelper.
The null doesn't look to be an issue in the first and third.

The other option I can see would be something like changing line 595 of
SquirrelUpdateManager.ApplyReleases.cs from "var runningProcesses =
UnsafeUtility.EnumerateProcesses();" to "var runningProcesses =
UnsafeUtility.EnumerateProcesses().Where(p => p.Item1 != null).ToList();"

Both work but if you have a preference (or a different option) let me know
and I'll be happy to handle it as such in the PR.

Thanks,

Dane

On Wed, Jun 14, 2017 at 12:37 PM, Paul Betts [e-mail]
wrote:

@DaneVinson https://github.com/danevinson Thanks for the debugging and
the future PR!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Squirrel/Squirrel.Windows/issues/1024#issuecomment-308536018,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADw0fbResCxMr_N7hKTUpvyNnTT_lqaVks5sEDaCgaJpZM4NbFdA
.

[anaisbetts]

Fixed it!

[markmcdowell]

Ah awesome I was just looking into this. Will the fix be in 1.7.6?

[ralsu091]

Thank you All! That definitely fixed it for us!

[the-j0k3r]

@paulcbetts not quite fixed, its better, but is it really fixed?

see https://github.com/atom/atom/issues/15320 the issue was closed because of this fix, but myself and others are still experiencing less than desirable garbage collection.

Note: from here down its comments after the fix was added in https://github.com/atom/atom/issues/15320

For my part, the last update from atom 1.20.0 -> 1.21.0 -> 1.21.1 leaves the 1.20.0 directory behind, many errors on squirrel log.

Edit screenshot

Others have up to a dozen older installs directories unaffected by this fix.

My squirrel log for your perusal https://gist.github.com/the-j0k3r/78e02a97a7a17a24aff696dc2f0757d2

~> atom -v  

Atom    : 1.21.1  
Electron: 1.6.15  
Chrome  : 56.0.2924.87  
Node    : 7.4.0  

~> apm -v

apm  1.18.5  
npm  3.10.10  
node 6.9.5 x64  
python 3.5.2  
git 2.14.2.windows.1  
visual studio

[the-j0k3r]

@paulcbetts this issue needs to be reopened, please.

[anaisbetts]

@the-j0k3r This is because Atom disabled ASAR and made directories with paths too long to delete. They've switched back to ASAR now, so if you one-off clear them yourselves they should be gone for good.

[the-j0k3r]

Would you known at what version of Squirrel that was?

I already did a one off clear at Atom 1.20.0 because like many I had quite a lot of builds.

[anaisbetts]

@the-j0k3r All versions of Squirrel (including the current one) will be unable to delete super long paths. Atom shouldn't generate them, but two versions of Atom's installer _did_. This is generally an Atom bug.

[the-j0k3r]

Since Im no where closer to an actual solution but manually deleting stuff and after subscribing to various reports now all closed, I cant say I care that much to keep beating that drum.

A quick batch script to delete these old dirs and unwanted contents is faster to write than this chasing game of so many components and what bug to report and where.

Thanks for your replies. Ill leave it to the pros.

[anaisbetts]

@the-j0k3r The bug is already fixed, but the fix is not retroactive, is the 10-second summary. People who install Atom today from scratch will not see this bug, at all

[the-j0k3r]

Paths wise the 1.20.x paths are no more longer or shorter than the current ones, so again, Ill just stick with my script and stop chasing this white rabbit.

Will keep monitoring what happens after the next upgrade, but finger on the script button so to speak.