Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Filesystem watcher error when watching disk root directory on Windows #5578
External W7 computers as send only, I have a backup server that is receive only. All been fine up until the last update. was on rc2 with no errors
On the remote computers im getting a title of Filesystem Watcher Errors and errors as follows
GetFileInformationByHandle ?\C:: Incorrect function.
on the computers where the software is running and on the network shares…
The network name cannot be found
Although I am able to access the remote folders through explorer. I have also noticed on the sync job rescan section it’s now saying “Failed to setup, retrying”
I have shutdown and restarted Syncthing and get the same issue.
It also seems that the syncs are working so maybe the error is benign / false.
If this will be confirmed to only affect folder roots at drive letter level, this might be related to rjeczalik/notify#148. Even if it's not it's relevant, as it essentially means drive letter watches were ineffective even before this error.
Short term workaround: Disable watching for changes for root level folders.
I've commented on this issue on the Forum, but to duplicate the comment, I'm seeing the same behavior.
v1.1.0, Windows (64 bit) installed via SyncTrayzor v1.1.22 on Windows 10 Pro Evaluation build 18351.19h1_release.190301-1611.
The share is the root of a non-OS drive, with a few exclusions on the root level and excluding System Volume Information.
My reading of this is that from version 1.1 and moving forward syncthing will not be able to work on XP at all, or am I miss reading it and after this bug is fixed it "might" start working again?
referenced this issue
Apr 2, 2019
This was referenced
May 8, 2019
Turns out I need to change non-test code to make this scenario testable, which in itself already makes it unlikely that the mistake that has lead to the panic happens in the first place (unless there is write access to a drive root on the test system, then the scenario wouldn't have to be faked, but that's hardly possible).
Are you ok with a test of the scenario that has lead to the panic, that can only run after code changes also in this PR?