You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.
This issue doesn't manifest in any user visible behavior immediately (it may if you try to recreate a folder reusing one of the older names), but it does leave file watchers in a bad state.
The main problem here is that invalid change events are fired with the old path name, e.g. C:/Program Files/Brackets/dev/samples/root/Getting Started/New folder/README.md. It seems that windows file watchers are smart enough that they stay with a folder even after it's renamed.
@peterflynn also noted that subfolders should also be unwatched and suggested an API change to FileWatcherDomain to add a method for unwatching all paths that start with a prefix.
The text was updated successfully, but these errors were encountered:
Correction, I did find some user facing behavior. After following the above steps...
In Explorer, create another new folder, name it foo (remember that bar presently progressed from New folder->foo->bar)
Paste in any single file into foo
Observe file tree
The file pasted into foo does not appear
A new file watcher was never created for the new foo folder because the FileWatcherDomain hit it's watcher cache and does not add a new watcher for the new foo folder.
Discovered this issue in PR #6546 when fixing #6537.
AppshellFileSystem._enqueueChange
insert a conditional breakpoint to log change events:console.log(changedPath),false
foo
bar
bar
This issue doesn't manifest in any user visible behavior immediately (it may if you try to recreate a folder reusing one of the older names), but it does leave file watchers in a bad state.
The main problem here is that invalid change events are fired with the old path name, e.g.
C:/Program Files/Brackets/dev/samples/root/Getting Started/New folder/README.md
. It seems that windows file watchers are smart enough that they stay with a folder even after it's renamed.The issue is due to the fact that we don't unwatch a folder after a rename. I have a patch for that in a closed PR https://github.com/adobe/brackets/pull/6546/files#diff-0.
@peterflynn also noted that subfolders should also be unwatched and suggested an API change to
FileWatcherDomain
to add a method for unwatching all paths that start with a prefix.The text was updated successfully, but these errors were encountered: