FindFirstFile error

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. Forum

Menorca FindFirstFile \?\c:: El nombre de archivo, directorio o etiqueta del volumen no es válido.

with the update to 14.50 now both windows remaining in the sync servers are throwing these error, there wasn’t any change in the servers. I tried to change the C to c, but the error persist.

any workarround ? i looked at the forum and the message found is from 2015.

Google translate (well, you actually don’t need to translate to understand :stuck_out_tongue: ): The file name, directory, or label of the volume is not valid.

What’s the folder root path of the affected folder?

from the error message Menorca FindFirstFile \?\C:: El nombre de archivo, directorio o etiqueta del volumen no es válido.

syncthing config folder C:\documentos compartidos\NewSync\Menorca

windows explorer folder C:\documentos compartidos\NewSync\Menorca

msdoc folder C:\documentos compartidos\NewSync\Menorca>

Weird, everything looks quite normal. Seems like some weird windows quirk - google doesn’t help me. Maybe someone with windows experience recognises the message.

I am having the exact same issue. I just downgraded back to v0.14.49 and the problem goes away.

I wasn’t able to resolve the issue on 0.14.50 even with changing the folder name or re-adding folders. It happened to all three windows machines that I have using SyncThing which were all set to auto-upgrade (which I’ve now disabled.)

1 Like

How did this not happen to a single RC user?!

Can any of you run Go scripts (i.e. have Go installed or are willing to)? I.e. I provide a small script where you’ll need to enter a folder root path resulting in the failure and it will check a few things to narrow down the source of the problem.

Tell me exactly what you need me to install and what to run and I’ll do it for you :slight_smile:

Seeing the exact same error after automatic update to v0.14.50, Windows (32 bit), on two old machines with Windows XP Pro SP3. Haven’t tested extensively, but sync appears to be working both ways in spite of the error message on both PCs.

So what’s the best solution, roll back to v0.14.49 and stay there, or hope that a future release will fix the error? Will v0.14.49 keep working indefinitely (as long as XP :wink:)?

1 Like

Waiting for a fix, we still can ignore or disable fsWatcher

Xp is not supported so if it works, it’s an accident


The same here, The error is appearing only on an XP machine, I use syncthing because an i386 version is supplied.

Any ideas or do I need to wait for the next version,


1 Like

Install Go: Download and install - The Go Programming Language
Get the script and adjust the folderRoot variable: Script to debug · GitHub
On the command line, navigate to the place where you saved the script and run go run debug.go.
Post the output here.

Okay I did what you asked, this is what I get:

C:\Go\scripts\debug.go:13:29: unknown escape sequence

The directory was:

var folderRoot string = "P:\my data\health"

I figured perhaps the script needs double slash to work so I did it that way also:

var folderRoot string = "P:\\my data\\health"

And this is the output I got:

folderRoot: P:\my data\health
After drive hack, folderRoot: P:\my data\health
ExpandTilde: P:\my data\health <nil>
folderRoot is absolute
After longFileNameSupport, folderRoot: \\?\P:\my data\health
EvalSymlinks failed: FindFirstFile \\?\P:: The filename, directory name, or volu
me label syntax is incorrect.

Hope this is helpful :slight_smile:

Thanks a lot, that was speedy :wink:

My bad, the path should be enclosed in backticks.

Until now it just shows that the error is indeed coming from filepath.EvalSymlinks, but not yet why. I updated the script to check something else, could you run it again please: Script to debug · GitHub

Sure here you go:

folderRoot: P:\my data\health
After drive hack, folderRoot: P:\my data\health
ExpandTilde: P:\my data\health <nil>
folderRoot is absolute
After longFileNameSupport, longRoot: \\?\P:\my data\health
EvalSymlinks on \\?\P:\my data\health failed: FindFirstFile \\?\P:: The filename, directory name, or volume
 label syntax is incorrect.
EvalSymlinks on P:\my data\health failed: <nil>
1 Like

Ok thanks, now it’s clear what’s causing the problem, but not why it is happening. Meaning it’s easy to work around, but the problem shouldn’t occur in the first place. Which version of windows are you running?

I tried the test on Windows 10 and Windows 2012 R2 and got the same result on both.

I run SyncThing usually on several Windows Server 2012 R2 servers.

1 Like

After running the test on other drives in my system such as C, D, R etc it appears to work on those. But it won’t work on P. For example:

folderRoot: T:\Test
After drive hack, folderRoot: T:\Test
ExpandTilde: T:\Test <nil>
folderRoot is absolute
After longFileNameSupport, longRoot: \\?\T:\Test
After EvalSymlinks, evalRoot: T:\Test
After longFileNameSupport, evalRoot: \\?\T:\Test
rooted("", %v): %v, %v \\?\T:\Test \\?\T:\Test <nil>

The only thing I can think of is that P:\ on my systems is a RAMDISK. So it’s not a real physical disk and is instead created by software. Specifically IMDisk a driver.

All the prior versions of SyncThing worked fine with it though, no problems of any kind syncing folders/files with the RAMDISK. I’ve actually never had software that had an issue seeing or utilising it before, sometimes it even fools disk utilities.

Think that could be related?

The previous Syncthing version didn’t “work”, it just ignored this error, which didn’t have any consequences for you, as you don’t have symlinks in place.

It looks like the FindFirstFirstFile syscall is not supported with long path names on your driver (paths prefixed by \\?\).

See issue and PR

Thanks for the workaround.