File watching doesn't work for external edits made through symlinked folder

[njx]

[Updated to indicate that this is because of symlinks]

1. In a standard Brackets hacking setup (with a dev symlink in the brackets-shell folder), launch Brackets and open the Getting Started project (which should be open through the dev symlink)
2. In an external editor, open the Getting Started index.html from the brackets repo directly (not through the dev symlink)
3. Edit the file in that editor and save it
4. Switch back to Brackets

Result: No dialog, no auto-refresh of file.

[pthiess]

@njx not sure this is a must fix for Cycle 36? @bchintx Please take a look into this.

THX!

[njx]

Oh, I thought I had edited this, but I guess I didn't save the edits. It's only happening if you have the file opened through a symlinked folder. I don't think it's a stop ship for 36. I'll fix it again.

[njx]

Nominating for 1.0. Symlinks are pretty common on Unix, and the fact that we miss watcher events in this case seems like it could lead to data loss.

[peterflynn]

Reviewed - keeping in 1.0 to investigate whether there's a cheap way to have symlinked files/folders treated as non-watched files (which would allow the file to update in step 4). This may be technically difficult, however.

We also considered whether there's anything simple we can do to indicate that a file isn't watched (which would include both symlinked items, once the above is fixed, as well as files outside the project root and files inside the project but filtered out by the watch-root filter)... but that seems less critical. Unwatched files that we correctly treat as unwatched (unlike the bug above) aren't so badly behaved anyway.

[njx]

Reassigning to @peterflynn

[peterflynn]

To fix this, we need to get FileSystemStats.realPath to accurately be reported on all three platforms:

• Mac -- appears to be working correctly
• Win -- brackets-shell has code that tried to implement this, but afaict it's not working -- realPath is always null even for files behind a symlink, in my testing
• Linux -- not implemented at all yet

So there would be some native work to fix this. Adding 'needs review' to evaluate if we want to take that on for 1.0 or not.

[peterflynn]

Note: to test this on Mac or Win you need to be a little bit careful: the native Open dialogs on both OSes automatically normalize out symlinks if you click into one directly. If you use File > Open to open a file inside a symlinked folder, Brackets will be handed the real path instead; similar if you use File > Open Folder to open a symlink as the root of the project.

The best way I've figured out to actually expose Brackets to a symlink is to have the root of your project be a regular folder that contains a symlink as a child. Then expanding the symlink in the Brackets folder tree lets you access files using the symlinked path.

[dangoor]

Reviewed and opted for "not 1.0". (Removing needs review label). Thanks for the extra notes on this, Peter!