Files don't always update correctly: files can exist twice in a single framework

[mauritslamers]

Using the BT I ran into an issue already reported earlier by Topher Fangio, which is that sometimes certain files don't seem to get updated when a file on disk changes. Investigating this problem, I found out that it is possible somehow that a file gets created twice in the same framework. The fsevents process (on Mac) will update a different file object than the server will return, resulting in the impression that a file doesn't get updated, where it effectively does, but the wrong file object is returned by the server. It is possible that this is triggered in a delete / create (rename) process where a new file is added to the system where an existing file already has that path, or the original file didn't get destroyed.

[topherfangio]

To shed a bit more light on the issue, I have only noticed it with framework files, not app files, and you're absolutely right that it returns two files. It's very strange because I've actually modified my file (Version A), reloaded, modified it again (Version B) and seen the change, then modified it one last time (Version C) and when I reload, I'm presented with Version A...

Restarting the server always fixes this.

As a side note: this seems to be the same exact issue that appears when using symlinks except that it ALWAYS occurs instead of the sometimes with a regular framework file.

Anyway, let me know if there is anything I can do to help :-)

[topherfangio]

Not sure if this helps track it down or not, but when this happens, I actually see all files served simultaneously.

Here is a gist of what I mean: https://gist.github.com/topherfangio/5919b2311a5311a3e343

Note how there's actually 4 copies of the file being served to the browser.

Am I providing anything useful at all, or did you already know this? :-)

[mauritslamers]

This is new for me, but it shows that obviously there is a problem.

I am not sure what the best way would be to solve this. We could either try to find the source of the bug, or work around it by introducing a file manager which centrally watches all files and directories and updates the rawContent of the file. It would save memory as well as shave off some startup time (for example to not have to read all the sproutcore files once for every app). It would also be interesting to think of what processing is context-less enough to be included in this file manager. (sc_super comes to mind). Thoughts?

[nicolasbadia]

Isn't this issue fixed?

[mauritslamers]

I think so too. I haven't seen it since.