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
rsync-auto ignores subfolder directory changes #10966
Comments
Hi @polynomialdonut - after playing around with this myself, I think the issue might be with this change #10902. I noticed that the listener wouldn't pick up changes from files inside a given subfolder, but files at the root of the share foldergets picked up... 🤔 I recommend rolling back to the previous version, as I believe what you were doing shouldn't be affected by the bug I linked to. |
Thank you for your reply/efforts @briancain, the changes are in a subfolder, and I just rechecked - they are picked up instantly, presumably due to the changes I mentioned above. I might retry the old settings to confirm that they would still lead to certain files being ignored (can't do it right now since I should get some things done at work, first). |
It is a pattern matching issue. We have seen this too. we exclude If I am reading this correctly exclude is interpreting |
Hi @jweir - I don't believe that's the case. Having a folder
If you use a As I mentioned earlier I believe the issue seems to be that the watcher only seems to be watching the top most directory level of a folder, and doesn't seem to pick up any sub directory changes. |
All our files are initially syncing as expected. All files and directories are watched as expected, except any directory or file which matches an exclude entry. If excludes is
If I
But, you can not prepend an exclude with a The previous version of I have tried to trace the code through to understand how this all works better, but I have gotten a bit lost. In other words, I might not be helping at all here. So, if the above is not useful, I will be quiet now. 😄 |
Fixes #10966: Ensure all subdirectory files are watched
* commit '07a51906769ad1d717e9246a67d3dc4fc57e84a9': Update CHANGELOG Update CHANGELOG Update CHANGELOG Fixes hashicorp#10950: Ensure pip_install_cmd is finalized Fixes hashicorp#11027: Ensure VM id is passed to list snapshots Update CHANGELOG Move around example mention in docs Docs: Add note about running bash with the `run` option for triggers Fixes hashicorp#10966: Ensure all subdirectory files are watched Fixes issue hashicorp#10973: checks that VMMS WMI reference is null & throws appropriately ansible_ssh_host in the example is deprecated
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Vagrant version
2.2.5
Host operating system
Ubuntu 18.04.2 LTS
Guest operating system
Ubuntu 16.04.6 LTS
Vagrantfile
Expected behavior
The file
#{DIR_HOST_CHANGED_REPO}/modules/pfcp/messages.c
should have been updated inside the guest at#{DIR_GUEST_CHANGED_REPO}
after writing to it on the host side.Actual behavior
It was not updated. No error output was printed, so
rsync
didn't fail, either.Steps to reproduce
vagrant up
#{DIR_HOST_CHANGED_REPO}/modules/pfcp/messages.c
on the host side inside the source folder of the host-to-guest sync specified in the Vagrantfile.Possible source of error
I am suspecting that there is some conversion from the list items given by
rsync__exclude
to regular expressions forrsync-auto
going on, and that*.so*
or*.o*
got converted the wrong way; afaikrsync
is understands that.
is a literal dot, but maybe the conversion tool assumes a.
means we have a single character, so ghat*.o
actually acts as if we had passed*o
, which would then exlude#{DIR_HOST_CHANGED_REPO}
, since the variable ends on an 'o'.After changing the exclude line to
syncs were quasi-instantaneous.
Also, on the initial sync, everything was copied into the guest, so there seems to be some difference between how the initial sync works (and it did) and how rsync-auto syncs work.
The text was updated successfully, but these errors were encountered: