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

Writing to config in deactivate can wipe settings #17060

Arcanemagus opened this Issue Mar 31, 2018 · 4 comments


None yet
6 participants

Arcanemagus commented Mar 31, 2018



When a package writes to the configuration during it's deactivate step there is a chance it can cause Atom to wipe the user's settings when Atom is restarted (such as during updating packages).


Steps to Reproduce

  1. Create an empty folder and set the ATOM_HOME environment variable to this folder's path
  2. Download, extract it, and run apm link from that folder in the environment from step 1
  3. Launch Atom, you should get an information notification saying the current value is 0, 0, 0, 0, 0, as well as Atom's regular first run screens
  4. Set the Welcome screen to disabled in order to make it obvious when this bug hits you.
  5. Launch "enough" Atom windows to trigger this bug on restarting, I found 10 windows to be a good number
  6. Close one of the windows and launch a replacement
  7. Note that the number increments
  8. Open the developer tools and run atom.restartApplication() to restart Atom
  9. Either the configuration will save and you will simply see an incremented number, or Atom's configuration will reset and you will see all 0s again, and the Welcome screen will show in all windows
  10. If the settings didn't reset, simply run the command again until it does.

Expected behavior: Atom's configuration doesn't get wiped.

Actual behavior: Atom's configuration occasionally gets completely reset.

Reproduces how often: This is somewhat hard to tell, initially it was around 80%, but it can take many calls to atom.restartApplication() to reproduce this. Atom v1.26.0-beta0 reproduces this more often than Atom v1.25.0 does, but both versions do reproduce this.


Atom    : 1.26.0-beta0
Electron: 1.7.11
Chrome  : 58.0.3029.110
Node    : 7.9.0
apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.26.0-beta0
python 2.7.14
visual studio 2015

This bug has not been seen to reproduce in Atom v1.24.1.

Additional Information

This is a split out of the remaining part of #14909.

The common packages in all 24 package lists posted to that issue was the following:

"package name", "min", "max"


linter-ui-default has the possibility to call atom.config.set during deactivate, leading to the guess in #14909 (comment) that lead to the test package in this issue.

The change to writing the configuration file in a single process was made in #16628.

@Arcanemagus Arcanemagus referenced this issue Mar 31, 2018


Settings lost #14909

0 of 1 task complete

This comment has been minimized.

Zireael07 commented Mar 31, 2018

That's some great sleuthing...


This comment has been minimized.

andrew-aladev commented Apr 5, 2018

Hello. I am using git in ".atom" folder. Today I've received the most epic config.cson I've ever seen.

"*": {}
    allowPendingPaneItems: false

What is "ore:"? It looks like something is wrong with code writing config.


-  core:
+"*": {}

This comment has been minimized.


maxbrunsfeld commented Apr 19, 2018

Close this out in light of #17166 (comment).


This comment has been minimized.

lock bot commented Oct 22, 2018

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

@lock lock bot locked as resolved and limited conversation to collaborators Oct 22, 2018

@atom atom unlocked this conversation Nov 13, 2018

@lee-dohm lee-dohm reopened this Nov 13, 2018

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