This repository has been archived by the owner on Sep 6, 2021. It is now read-only.
[File Watchers] Creating file, then moving it over other file, can make us miss the file change #6609
Labels
Milestone
Comments
ghost
assigned
peterflynn
added a commit
that referenced
this issue
Jan 23, 2014
added/removed lists - because there's a delay between the change occurring and the time we re-read the dir contents in response, we might see back-to-back changes (e.g. a delete-recreate pair) as a no-op even though something definitely changed. See #6609 for an example bug. Updated docs to clarify the two different special cases of directory change events. (Also contains an unrelated small docs improvement in FileUtils). ProjectManager already responds to this special case the way we'd want - it calls FileSyncManager and then does nothing else - so no code changes needed there.
peterflynn
added a commit
that referenced
this issue
Jan 23, 2014
Enhance MockFileSystemImpl to allow artificially delaying watcher notifications in addition to delaying normal callbacks.
peterflynn
added a commit
that referenced
this issue
Jan 23, 2014
…from-release * origin/release: Typo fix Unit test for bug #6609 (Fast file replacement operations can be missed) Dispatch a FileSystem "change" event even when a dir change yields empty added/removed lists - because there's a delay between the change occurring and the time we re-read the dir contents in response, we might see back-to-back changes (e.g. a delete-recreate pair) as a no-op even though something definitely changed. See #6609 for an example bug.
|
FBNC @njx, though you've tested it already so feel free to close immediately if you want |
|
Verified, closing. |
peterflynn
added a commit
that referenced
this issue
Jan 30, 2014
…ile-system * origin/master: (1140 commits) Typo fix Set sprint 37 Add session scope Fix signature of `setValueAndSave` Unit test for bug #6609 (Fast file replacement operations can be missed) Dispatch a FileSystem "change" event even when a dir change yields empty added/removed lists - because there's a delay between the change occurring and the time we re-read the dir contents in response, we might see back-to-back changes (e.g. a delete-recreate pair) as a no-op even though something definitely changed. See #6609 for an example bug. Update NOTICE Define self to prevent exception, for #6607 Better doc comment for `Scope.set` Changes based on review comments Maintain the original line endings in preferences files Properly reconfigure the user prefs in test windows. Set preferences are, by default, set in the context in which they are defined. Nits fixed revert submodule add add required success/error callbacks for jstree load_node Nit fixes after PR #6123 Updated by ALF automation. Setting the side toolabr to the top remove unwatchPathsWithPrefix and consilidate with unwatchPath ... Conflicts: package.json src/config.json src/document/DocumentCommandHandlers.js src/extensibility/ExtensionManager.js src/filesystem/FileSystem.js src/filesystem/FileSystemManager.js src/nls/root/strings.js src/project/ProjectManager.js src/styles/brackets_patterns_override.less src/utils/ExtensionLoader.js
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It's somewhat common for apps to write to a file by first writing the new contents to a temporary file, then deleting the original file and moving the temp file over to where the original file is. If this all happens quickly enough, Brackets can miss the change.
I don't have an isolated repro case yet but could probably build one easily enough in Node.
The text was updated successfully, but these errors were encountered: