New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

My installer doesn't seem to remove old versions... #1024

Closed
JonZso opened this Issue May 15, 2017 · 16 comments

Comments

Projects
None yet
7 participants
@JonZso

JonZso commented May 15, 2017

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

@Slion

This comment has been minimized.

Slion commented May 20, 2017

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

This comment has been minimized.

DaneVinson commented Jun 8, 2017

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

@DaneVinson

This comment has been minimized.

DaneVinson commented Jun 14, 2017

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.

@paulcbetts

This comment has been minimized.

Member

paulcbetts commented Jun 14, 2017

@DaneVinson Thanks for the debugging and the future PR!

@DaneVinson

This comment has been minimized.

DaneVinson commented Jun 14, 2017

@paulcbetts

This comment has been minimized.

Member

paulcbetts commented Jun 14, 2017

Fixed it!

@markmcdowell

This comment has been minimized.

markmcdowell commented Jun 19, 2017

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

@ralsu091

This comment has been minimized.

ralsu091 commented Jul 11, 2017

Thank you All! That definitely fixed it for us!

@the-j0k3r

This comment has been minimized.

the-j0k3r commented Oct 13, 2017

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

see atom/atom#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 atom/atom#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

capture

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

This comment has been minimized.

the-j0k3r commented Oct 21, 2017

@paulcbetts this issue needs to be reopened, please.

@paulcbetts

This comment has been minimized.

Member

paulcbetts commented Oct 21, 2017

@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

This comment has been minimized.

the-j0k3r commented Oct 21, 2017

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.

the-j0k3r referenced this issue in electron/windows-installer Oct 22, 2017

@paulcbetts

This comment has been minimized.

Member

paulcbetts commented Oct 23, 2017

@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

This comment has been minimized.

the-j0k3r commented Oct 23, 2017

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.

@paulcbetts

This comment has been minimized.

Member

paulcbetts commented Oct 23, 2017

@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

This comment has been minimized.

the-j0k3r commented Oct 23, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment