Open core-ai-bot opened 3 years ago
core-ai-bot
commented
3 years ago 
I have the same problem. Files updated outside Brackets are not updated inside Brackets even if I do close/open of the files in the editor - only after reloading Brackets the new content of the files is shown.
core-ai-bot
commented
3 years ago 
I think I saw this once, but was never able to reproduce it.@Globegitter and@dexbg, is this happening to you regularly? What platforms are you on?
core-ai-bot
commented
3 years ago 
@njx It happens to me fairly regularly, maybe even all the time (at least in my 2 stated use cases). I am running it on Mac OSX 10.9
Edit: Now just did a git pull and it worked. So it is not all the time.
core-ai-bot
commented
3 years ago
I also get the problem regularly - I'm running it on Windows 7 and Ubuntu 13.10.
core-ai-bot
commented
3 years ago core-ai-bot
commented
3 years ago core-ai-bot
commented
3 years ago core-ai-bot
commented
3 years ago core-ai-bot
commented
3 years ago 
@dexbg Do you have any steps that can reliably reproduce the problem for you (preferably on Windows rather than Ubuntu?)
core-ai-bot
commented
3 years ago
Well, I have Gulp task that changes several files. I run the Gulp task from within Brackets (i.e. using Alt+N). After the files are changed (by Gulp) while I'm still in Brackets - I don't see the updated content of the changed files .
core-ai-bot
commented
3 years ago
@dexbg Any time you launch Brackets and run Gulp that way, you consistently don't see the files update? That seems good to know. Which extension are you using to run Gulp?
@dexbg@Globegitter if you notice files not updating again, can you use "Show Developer Tools" from the Debug menu and copy console output over to this bug so we can see if there are errors in there?
core-ai-bot
commented
3 years ago 
@dexbg@Globegitter Another thing you can do in dev tools that would be helpful:
_fileWatcherChange() (~line 100)console.log("Change", event, path, name, new Date())Then the next time you hit the bug, check the console and see if there were any changes logged for the file that was modified without Brackets noticing it. (You can use the timestamp on each line to make sure the logged changes are actually recent).
This will tell us if the watchers are firing an event that Brackets loses somewhere later along the way, vs. if the watchers aren't even firing at all. It would be very helpful data to have. Thanks!
core-ai-bot
commented
3 years ago
Progress! Here's a rather lengthy comment describing what I think we know so far (via@dangoor and@peterflynn).
FileWatcherDomain.watchPath() (on the Node side). And when we get this "rename" change back in Brackets, we treat that as a change for the entire parent directory, which calls Directory._clearCachedData() to blow away the caches of all the directory's children as well as its own content listing. In theory, that should deal with any such unknown change.Directory._clearCachedData(). For each of its children, it tells it to _clearCachedData(true) - meaning that if the child is a directory, it will clear its cached content listing, but not clear the caches of its children. So, if later on one of those children changes in the same way, and that child directory gets _clearCachedData() call again, it won't clear the caches for its own children (i.e. the grandchildren of the original directory), because its cached content listing has already been nulled out, so it doesn't know who its children are.That seems to be exactly what's happening in this cmv4 case - what happens is that a change to a file directly within the src folder blows away the cached listing for src/editor, so later on when a change happens inside src/editor and we treat it as a change to the whole directory, it doesn't blow away the cache of the file on which the change actually happened.
One fix would be to make it so that if a directory doesn't have a cached content listing and it's told to clear its cached data, it looks through our entire internal file index to find files that are inside itself and blow those caches away. That might be a little expensive though.
core-ai-bot
commented
3 years ago
(Also, we might want to dig into why we're getting these weird "created" events.)
core-ai-bot
commented
3 years ago
I'm going to post a quick fix for testing in a min.
core-ai-bot
commented
3 years ago
@njx@dangoor Tentative fix posted to pflynn/file-caching-fix if you want to try it out. (Needs unit tests before it's PR-ready, though)
core-ai-bot
commented
3 years ago
That fix seems to fix the general problem. If I switch branches really quickly, I can still get a race condition where the current editor gets out of date. However, if I then close and reopen the file, it gets the new content. So that's probably a different race somewhere further up the chain.
core-ai-bot
commented
3 years ago core-ai-bot
commented
3 years ago
@peterflynn In an effort to learn a bit more about the filesystem, I created a test for this that fails on master but passes on your branch. It's in 0ce44ddd3c9b12a30cf92418985e835e61f2a4bb (on the branch dangoor/file-caching-fix-test).
I like how testable this code is!
core-ai-bot
commented
3 years ago core-ai-bot
commented
3 years ago
BTW, for posterity, this problem was reproducible when switching between master at c59c542 and cmv4 at 917a46c.
core-ai-bot
commented
3 years ago
@Globegitter@dexbg the fix for this is in master now, and will be in release 37 (coming out soon!)
I'm going to close this one. If you spot any issues like this in 37 (or on master now, if you're running from the Brackets source tree), please either reopen this issue or file a new one.
core-ai-bot
commented
3 years ago 
:+1: .@peterflynn unsubcribing. mention me to alert me.
core-ai-bot
commented
3 years ago 
I'm still seeing this in sprint 40 (Windows 7 64bit, running as non-admin).
If I [bower install some-package --save] Brackets won't see the new folders/files in bower_components, even with a manual file tree refresh (right click). Even with the bower.json closed (not in the working files panel) clicking it shows the old version, yet the file has been changed/overwritten by the bower install and viewing in another editor shows the updated version.
Can't really trust my eyes with this right now.
Edit: typical. Another day and I can't reproduce. I did have Intel XDK (which also uses Brackets, though its own install of it, I think) open, so will try a few experiments with order of opening etc.
core-ai-bot
commented
3 years ago
@PipStyles Can you open a new issue? We definitely fixed problems with this one in March, and it would be good to try to narrow down what you're seeing now.
(Also, in the new issue, if you can add whether you're able to consistently reproduce this in any way and if there's any console output when you Show Developer Tools from the Debug menu...)
Thanks (and sorry about the problem!)
While the latest spring improved the state of Bracket a lot, the File Watcher still doesn't seem to be working a 100%. For example if I create a new branch in my git repository, edit some files and switch back to master, the files don't get updated.
Also when I run things like
bower installthe newly created files don't get displayed.Not sure if that has already been fixed, but thought I would mention it, since I ran into that a few times now. Really appreciate all the work btw.