Get a console error if you open a project using "Application Support" or its parent folder.

[RaymondLim]

1. Drag your "Application Support" folder from Finder to Brackets to use it as a new project.
2. From project drop down list switch to the previous project.
3. Open Developer Tools from Debug menu.
4. Look in the Console Tab or click on the error icon in the status bar.

Result: You will see one console error.

Blind write attempted:  /Users/rlim/Library/Application Support/Brackets/state.json 1395536064000 null AppshellFileSystem.js:426

Although we allow blind write in sprint 36, we're not updating state.json in this case. (or maybe an out-of-order overwrite is taking out all the newly updates).

If you restart or reload Brackets, you will see the project you opened in step 1 as current project, not the one you switched in step 2 even if it is the default Getting Started project (issue #7299). Note that you can also reproduce it with Brackets cache folder.

[RaymondLim]

Add step 2 that is necessary for the console error.

This issue was discovered when helping @lkcampbell's to identify the cause of #7299. I was able to reproduce #7299 when dragging the entire user folder as the project root, but not with "Application Support" folder.

[peterflynn]

I'm almost positive the problem is the File entry for state.json being held onto after one of its ancestor folders undergoes an unwatch() (more details in my note in #7299). We should probably close one or the other of these as a dupe.

[peterflynn]

Also, seems unlikely to be Mac-only... just easier to hit on Mac since opening ~ will hit this case, whereas on Win you'd have to open a weirder folder to hit it.

[peterflynn]

Hmm, interestingly though FileStorage.save() & load() fetch a new File object every time... so either someone else is holding onto that entry, or something else funny is going on...

[RaymondLim]

Remove mac only label since I can reproduce it on Windows also.

[peterflynn]

Ok, I figured out what's going on:

1. We initially read state.json very early in startup (when the preferences modules first load). This sets the File entry's hash.
2. Later, we open the initial project. (Which triggers a no-op write to state.json, but that's irrelevant here).
   Now, here's where things diverge...
3. We switch to a different project - the old project root is unwatched
   • In the normal case, this means nothing special
   • In the bug case, since state.json was actually in the old project root, its File entry is killed off - FileSystem basically forgets it's ever seen that file before
4. We try to write the new 'last project' setting to state.json
   • In the normal case, this succeeds since we still have the hash from step 1
   • In the bug case, we create a brand-new, never-read File entry. Writing fails since FileSystem thinks we didn't read the file before trying to write it (hash is still undefined).

So, I think this is all normal & correct FileSystem behavior -- by design, you're not supposed to be able to write to a file if we don't have a guarantee that you've read it before. That constraint doesn't really make sense for the preferences code. So I think we should fix this by having PreferencesBase pass the blind option to write(), disabling that check.

We could instead try to do something clever to retain the old hash, or re-read state.json on each project load... but really, we probably want the hash check disabled all the time for prefs, not just in this one specific case. E.g. imagine some other app touches that file for some reason... then you keep using Brackets for a while. You wouldn't want all your view-state changes after the external-touch to be dropped on the floor. We really do want to overwrite the file in all cases, regardless of what its timestamp on disk says (which is how the old localStorage prefs worked too).

CC @iwehrman @gruehle @dangoor in case you guys might have different opinions. If not I can put up a PR with the simple fix tomorrow.