Uncaught Error: ENOENT, open 'undefined//Users/alopex/.atom/project.json'

[benogle]

From @SimyungYang on January 6, 2015 0:47

[Enter steps to reproduce below:]

1. start an atom editor with save-session plugin on
2. save action might cause this error

Atom Version: 0.166.0
System: Mac OS X 10.10.1
Thrown From: Atom Core

Stack Trace

Uncaught Error: ENOENT, open 'undefined//Users/alopex/.atom/project.json'

At fs.js:75

Error: ENOENT, open 'undefined//Users/alopex/.atom/project.json'
  at Error (native)

Commands

Config

{
  "core": {
    "disabledPackages": [
      "npm-install",
      "save-session"
    ],
    "themes": [
      "atom-dark-ui",
      "base16-tomorrow-dark-theme"
    ]
  },
  "editor": {
    "fontSize": 14,
    "invisibles": {}
  }
}

Installed Packages

# User
color-picker, v1.2.6
linter, v0.9.1
minimap, v3.5.0
save-session, v0.11.2
npm-install, v2.0.0

# Dev
No dev packages

Copied from original issue: atom/atom#4854

[benogle]

There are several reports of this. Something must have broken in the upgrade from 165 to 166.

See atom/atom#4855, See atom/atom#4856

[clhynfield]

I'm getting this one, myself, in every project I open. I'll take a peek around, see if I can be of any help.

[clhynfield]

I think @vraravam is onto something with this in #45:

Also noticed that the preference setting for ''dataSaveFolder' (which was set to '/Users/vijay/.atom/packages/save-session/projects') keeps getting removed from the '.atom/config.cson' file and this could be the reason for the beginning value of 'undefined' when this plugin is trying to figure out the location of the 'project.json' file.

save-session prepends dataSaveFolder to the path to project.json (looked up through @saveFolder), but since it's now undefined, it's literally prepending "undefined", which results in an invalid path. Looks like the default gets set in @saveFolderDefault, but I don't see where that gets called. Judging from #44, @wn9FHW2nhO doesn't, either.

[benogle]

@clhynfield what does your config contain for save-session? Config things did change in 166.

cc @maxbrunsfeld

[clhynfield]

  'save-session':
    'project': '/Users/clayton/.atom'
    'windowX': 0
    'windowY': 23
    'windowWidth': 1280
    'windowHeight': 773
    'treeSize': 201

Also, as @vraravam notes in #45, even when I set dataSaveFolder manually in ~/.atom/config.cson, it's gone again shortly after.

Oh, and it looks like Config.saveFolderDefault is supposed to be called at package activation time, but even if I yank it out of the conditional, and/or move it up to the top of save-session.coffee, it doesn't seem to set the config.

[benogle]

There were some large config changes in 166. @maxbrunsfeld should know more.

[maxbrunsfeld]

Looking into it now.

[maxbrunsfeld]

My first guess is that it's because dataSaveFolder is not present in save-session's config schema. Schemas are now enforced in certain cases where they weren't before.

Looking into it deeper to verify.

[clhynfield]

Thanks very much, @maxbrunsfeld, that was it. I added this to the default config in save-session.coffee, and the package is working as expected:

    dataSaveFolder:
      type: 'string'
      description: 'The folder in which to save project states'

I'll submit a PR shortly.

[maxbrunsfeld]

Great! Thanks @clhynfield.

[clhynfield]

Couple of asides out of this:

1. Direct file IO seems like a kludgy way to save project/workspace state—is there a more Atom-y way to do this?
2. The error messages and stack traces caused by this third-party package didn't implicate the package in any way. I imagine this could cause serious headaches for the core Atom team as packages proliferate.

[maxbrunsfeld]

1. The package system already allows packages to save and load state as part of activation and deactivation. I'm not familiar with all of save-session's functionality, so I don't know if loading its saved state at package activation time would work.
2. The notification system will associate errors with packages when possible, but often the stack trace doesn't contain enough information to do this. Perhaps we could use node's domain system to associate async stack traces with the packages that created them, but this might be more work than it's worth.

[clhynfield]

I figured serialization might be the way to do it. Dunno if @mpeterson2 has looked at that, but if I get the time, I'll see if it'll work. Thanks again, @maxbrunsfeld!

[mpeterson2]

I haven't had time to look into this yet. I see a few of you have forked this, so I'd be happy to accept a pull request if you guys can find a fix.

[clhynfield]

Working it up now, @mpeterson2. Thanks much.

[mpeterson2]

Just merged a few pull requests in that fixed the issue for me. Thanks for the help guys.

Reopen this if you still have issues.