After the update, I see this message on two computers that I use.
" For the following folders an error occurred while starting to watch for changes. It will be retried every minute, so the errors might go away soon. If they persist, try to fix the underlying issue and ask for help if you can’t. Поддержка
Work GetFileInformationByHandle \?\W:: Incorrect function."
How to repeir?
Full logs, version of operating system? What is W:? Network drive?
I also have the same problem. Version: 1.1.0 OS: Windows 7, 64bit Drive: D (local drive)
It works on my Windows 10 computer which also runs version 1.1.0.
I’ve raised this in github and it’s flagged as a bug
No. One of several local HDD
The same but mirror: 1PC) Version: 1.1.0 OS: Windows 7, 64bit Drive: W (local drive) 2PC) Version: 1.1.0 OS: Windows 10, 64bit Drive: D (local drive)
Are all of these roots of the drive?
I am also seeing the same message, it does not appear to be impacting sync. My share is the root of a non-OS drive, with a few excluded folders (and excluding System Volume Information).
v1.1.0, Windows (64 bit) installed via SyncTrayzor v1.1.22 on Windows 10 Pro Evaluation build 18351.19h1_release.190301-1611.
yes.
For me it also happens on the root of a non-boot drive.
If anyone with an entirely watchable (i.e. user readable) drive and have/can install go, could you please post the output of running (go run notifyWinRoot.go) after adjusting the drive letter variable to whatever applies to you: https://gist.github.com/imsodin/dbbbbd4c662cd16f66c1a9281a3df9ed
Thanks for testing. I am a bit confused, as I wasn’t able to find any relevant change to how paths are treated between 1.11 and 1.12 (as trailing backslash seems to be stripped in 1.12). Unless someone else is motivated to dive into this, I’ll have to get debugging on windows 
What do you think, should we do a “hotfix” on our side? (e.g. stripping \\?\ for drive letters when calling Filesystem.Watch)
Do we need \\?\ anywhere at all any more? Go 1.8 (!) added a change that should use long filenames “when possible” which I think should cover all the regular OS stuff. Maybe the filewatcher library does need it if it does direct syscalls, but then it could fixup the path to whatever is the right format, and maybe only do so if it’s longer 260 chars etc?
Need possibly no - at least I don’t think we use syscall or x/sys for anything FS related and I hope that path/filepath, if it needs to interact with the filesystem at all, does it through os. However it also shouldn’t hurt and the notify library definitely uses syscalls.
I would really welcome any sort of hotfix for this issue! I tried to work around the problem by making the NTFS volume available not only as D:, but also as a directory beneath C:, to no avail. Windows just resolves that link to the physical location D:, so I was back to square 1.
I really would like to avoid having to set up dozens of individual folders in my Syncthing setups just to work around this… 
The immediate hotfix is to disable watching for changes, relying on periodical scans to detect changes. However you’re right, at least a dirty fix should make it into the next release - it’s on my todo now.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
