-
-
Notifications
You must be signed in to change notification settings - Fork 586
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Weird "change" event firing in parent directory of renamed file #296
Comments
Can confirm this issue and expand on the conditions under which it appears. Given a folder structure of what/ever/else/Foo/Bar/ Condition 1: Anything inside a folder (for example Bar) is changed, no matter if it is a file change, a new folder is added, a file or folder is deleted, etc. Condition 2: There exists a file in the parent folder (in this example Foo) whose name starts with the name of the subfolder (for example Foo/Barbarian.js or Foo/BarberQuartet.js) Effect: Whenever chokidar encounters condition 1, it also fires a change event for all items matching condition 2. So any change inside the folder |
Can you please provide the output from listening to the |
with a file structure of
The watcher used for the output:
A save of page.js in visual studio results in the following output from a raw event listener:
A save of Page/globalization.coffee results in the following output:
|
As you can see, the file system is emitting |
Any ideas where the issue could come from? I am asking from a background of not knowing much about the internals of chokidar, how much of node's fs module it uses, etc. Would it be possible the bug is on nodes side? Or does it seem more likely it is farther on the OS side of things? |
For windows chokidar relies on node's The bug could be either in node or lower down in the system API it uses, but it would be worth reporting to node if it could be demonstrated with a simple script that only uses |
See if setting |
I did a small synthetic test, and could reproduce the issue, both for chokidar and for fs.watch Anytime a new file was added or removed from the folder Foo, a change event for the file foobar.js was sent as well. Some times (not everytime though) the same behaviour happened for changes to the file using notepad, which contrasts a bit to our problem in visual studio. In VS every change resulted in the buggy behaviour. This might be due to the mechanics VS employs while saving a file, maybe some temp file copying or similar. Another thing to note is that Here is the output when adding, changing, changing again, and deleting a new file in Foo.
code below
|
This phenomenon appears to be caused deeper at the system level. There's no bug in chokidar, nor anything that could be done at this level to correct it. Closing |
I have the same issue. Also fixed by using polling. |
* feat: always return a promise from the stopper function * Use undefined instead of null. * Update README.md
I am using Windows 7 64b.
Let's say I am watching the "dir1" directory. Inside, I have "dir2", "file1.txt". Inside "dir2" I have "file2.txt".
Whenever I rename "file2.txt" (is it possible to get a "renamed" event btw?), I get a "change" event on "file1.txt", don't know why.
Here is my test log (I am recursively watching the "./data" directory):
[Chokidar] add data\Nouveau document texte.txt // created a file
[Chokidar] add data\test2.txt // renamed
[Chokidar] unlink data\Nouveau document texte.txt // renamed to test2.txt, actually
[Chokidar] change data\blablabla.txt // weird event
[Chokidar] add data\bla\toto222.txt // renamed
[Chokidar] unlink data\bla\toto.txt // renamed to toto222.txt, actually
[Chokidar] change data\blablabla.txt // weird event
[Chokidar] add data\bla\tutu123.txt // renamed
[Chokidar] unlink data\bla\tutu.txt // renamed to tutu123.txt, actually
[Chokidar] change data\bla\toto222.txt // again another weird event
[Chokidar] add data\bla\toto\Nouveau document texte.txt // created a file
[Chokidar] change data\bla\toto222.txt // again another weird event
[Chokidar] add data\bla\toto\test3.txt // renamed
[Chokidar] unlink data\bla\toto\Nouveau document texte.txt // renamed to test3.txt, actually
The text was updated successfully, but these errors were encountered: