Storage serialization inside .atom making dotfiles yucky

[maddox]

Ok so, I keep .atom in my dotfiles. I keep a dotfiles repo mainly because I have multiple computers. This makes the /storage dir create a mess for me. It makes ~/dotfiles constantly dirty for me, not to mention, I dont really want those things synced across computers.

It'd be nice to see that stuff actually get stored in ~/Library/Application Data/Atom on OS X. This is where common application data goes, especially device specific things.

A lot of the stuff inside .atom would be useful to sync across computers and in dotfiles. This includes app settings, plugins, etc. Environment things.

It seems to me that state like window size (per project) isn't something anyone would want. Not to mention how often it changes.

I'd love to know if there is consideration being made about .atom and people putting it in their dot files. There is currently device specific things in there, as well as things you'd WANT to sync, like settings and plugins. It'd be a shame to just not be able to sync with dotfiles just because of the state that's being saved inside there.

[kevinsawicki]

Atom used to put state in ~/Library/Application Data/Atom but ~/.atom/storage was switched to partially to make it easier to clear out when things went wrong. Things shouldn't go wrong anymore though as the format has stabilized and Atom now handles incompatible versions when the format does change.

I'm down for moving storage back to ~/Library/Application Data/Atom.

[kevinsawicki]

Is it Application Support, not Application Data ?

[maddox]

yeah, ~/Library/Application Support/Atom. ~/Library/Application Data isn't a thing.

[maddox]

This is where applications are to store their needed information, namespaced by their application name.

[maddox]

speaking of, the Atom directory in there right now is using 1.71 GIGS, jeeeeeeeezus.

[kevinsawicki]

Yeah, looks like every version ever is in there.

[nathansobo]

Our serialization formats are insanely inefficient right now. It's a known issue. I think we need to switch from JSON to a binary format like protocol buffers for some of our stuff.

[probablycorey]

@kevinsawicki are the .node-gyp and .apm folders going to create a
similar problem?

On Fri, Nov 8, 2013 at 11:07 AM, Nathan Sobo notifications@github.comwrote:

Our serialization formats are insanely inefficient right now. It's a known
issue. I think we need to switch from JSON to a binary format like protocol
buffers for some of our stuff.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1094#issuecomment-28088717
.

[kevinsawicki]

@probablycorey Yup, we'd have to move those as well which should be straight-forward since they are just caches.

[probablycorey]

Also, I think the massive size for the storage files is because telepath locations are serialized (and the fact that it serializes every open buffer.)

[afeld]

👍 on moving storage/.

/cc github/gitignore#974

[lock]

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!