Skip to content
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

Filesystem watcher error when watching disk root directory on Windows #5578

Closed
tezfair opened this issue Mar 6, 2019 · 10 comments

Comments

Projects
None yet
6 participants
@tezfair
Copy link

commented Mar 6, 2019

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.

image

image

@calmh calmh added the bug label Mar 6, 2019

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

commented Mar 6, 2019

The folder path does not have a trailing slash which seems wrong.

Shut down, modify config by hand, start it back up and see of that fixes it.

@tezfair

This comment has been minimized.

Copy link
Author

commented Mar 6, 2019

I did, exactly the way you said via config, same result

image

this is another PC to my first posting, but same error

@imsodin

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

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.

@ggppjj

This comment has been minimized.

Copy link

commented Mar 8, 2019

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.

@ewpt3ch

This comment has been minimized.

Copy link

commented Mar 13, 2019

v1.1.0
@st-release st-release released this 8 days ago · 39 commits to master since this release
warning Notice warning
Due to adopting Go 1.12 and API changes there this release does not work on Windows XP / Server 2003 / Home Server. Syncthing 1.0.1 is the latest binary to "support" (it seemed to work, although was still not officially supported) those operating systems.

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?

@imsodin

This comment has been minimized.

Copy link
Member

commented Mar 13, 2019

This bug has nothing to do with XP, as you can see from reported Windows versions above. In addition this bug does not prevent Syncthing from working as a whole, just the watching for changes component.

imsodin added a commit to imsodin/syncthing that referenced this issue Apr 2, 2019

imsodin added a commit to imsodin/syncthing that referenced this issue Apr 2, 2019

imsodin added a commit to imsodin/syncthing that referenced this issue Apr 2, 2019

imsodin added a commit to imsodin/syncthing that referenced this issue Apr 2, 2019

@imsodin imsodin closed this in #5633 Apr 9, 2019

imsodin added a commit that referenced this issue Apr 9, 2019

@calmh calmh added this to the v1.1.2 milestone Apr 9, 2019

calmh added a commit to calmh/syncthing that referenced this issue May 8, 2019

@calmh calmh removed this from the v1.1.2 milestone May 8, 2019

@calmh

This comment has been minimized.

Copy link
Member

commented May 8, 2019

Reopen due to revert

@calmh calmh reopened this May 8, 2019

@calmh calmh changed the title Filesystem Watcher Error on v1.1.0 Filesystem watcher error when watching disk root directory on Windows May 8, 2019

calmh added a commit to calmh/syncthing that referenced this issue May 8, 2019

@imsodin

This comment has been minimized.

Copy link
Member

commented May 9, 2019

@calmh What's your opinion: Should I PR the fixed hot-fix (#5696 (comment)) again for the next RC or do you want to wait for the more general UNC-stuff (#5696)?

@calmh

This comment has been minimized.

Copy link
Member

commented May 9, 2019

A tested hotfix is fine for 1.1.4-rc imo

imsodin added a commit to imsodin/syncthing that referenced this issue May 9, 2019

imsodin added a commit to imsodin/syncthing that referenced this issue May 9, 2019

imsodin added a commit to imsodin/syncthing that referenced this issue May 9, 2019

@imsodin

This comment has been minimized.

Copy link
Member

commented May 9, 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?

Unrelated side-note: I think I found a bug in path/filepath, in that filepath.Join("D:", "foo") returns D:foo, while I expected D:\foo - I'll bring it up upstream. Apparently that's expected, as on windows there's a concept of relative paths on a specific drive, so D:foo means ./foo relative to the current directory on drive D.

imsodin added a commit to imsodin/syncthing that referenced this issue May 9, 2019

imsodin added a commit to imsodin/syncthing that referenced this issue May 9, 2019

@calmh calmh closed this in 2558b02 May 10, 2019

@calmh calmh added this to the v1.1.4 milestone May 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.