Syncthing 1.9 for Windows no more support the '\\?\UNC\' path format

Support
1

After upgrading to 1.9, Syncthing for Windows no more support the ‘\\?\UNC\’ path format.

Suppose to have a server ‘servername’ with a share ‘sharename’ with a subdirectory ‘folder\subfolder’ inside.
In Syncthing you would add a folder and specify the path ‘\\?\UNC\servername\sharename\folder\subfolder’.
Syncthing 1.8 is able to succesfully work inside this path and keep the files syncronized but as you upgrade to the 1.9 version you get the following error:
2020-09-11 11:25:23: Error on folder TestUncFolder: folder marker missing (this indicates potential data loss, search docs/forum to get information about how to proceed)

For references about UNC paths see:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

2

I’m not aware of any change here, though I’m amazed it ever worked.

3

I have just tested a UNC path on my Windows machine, and Syncthing seems to be able to use it just fine.

Could you give more details about your configuration (Windows version, etc.)?

4

There haven’t been any changes to this on Syncthing’s side since v1.8.0 and I am not aware of any changes on the go side of things. We do use the \\?\ prefix even if you don’t add it yourself to the path, so that’s unlikely to be the cause.

5

I am testing on a Window 10 x64 version 1909 build 18363.1082; the share in on another Windows 10 x64 version 2004 build 19041.508
The issue, however, is appearing also on Windows server 2008 R2 and on a Windows 7 on a share onto a Qnap Nas.
Please note that I am using the UNC prefix not on a fixed drive but on a network share, hence not a syntax like:
\\?\d:\folder\subfolder
(where Syncthing continue to work correctly) but
\\?\UNC\servername\sharename\folder

Note the ‘UNC’ part in the path to indicate a network share

6

You can try to enable debugging for model and/or scanner and see what errors pop out. We might be able to interpret those into something.

7

The problematic folder is named 'unctest’
From Windows command prompt issued:
set STTRACE=model,scanner
syncthing.exe

Output is uploaded in this post.

syncthing.log (6.3 KB)

8

Judging by the logfile, Syncthing is simply unable to find the .stfolder folder maker. You do have .stfolder present in the folder, right?

I personally am unable to reproduce this. I have tested with local and network folders using UNC paths, and Syncthing has no problems with recognising them, both under Windows 7 and Windows 10 (v1809 for what it is worth).

9

Yes, the folder marker is there but Syncthing is unable to find it.

To reproduce the issue you should upgrade to v1.9, the problem is with that version.

I have the Syncthing v1.7.1 and all goes right, but when it upgrades to v1.9 things goes wrong and it start to complain that folder marker is missing.

Give a try upgrading from 1.8 to 1.9, you should see it.

10

Well, all my tests were done with v1.9.0, so there is that.

Can you reproduce the problem using a different network folder, if possible shared from a different machine than the current one?

Also, do you perhaps have any firewall that could come into play here, e.g. blocking the new version of the Syncthing executable from accessing the folder? If you are using Windows Firewall, could you disable it for testing?

11

Issue is present on various Windows operative systems; tried on

  • Window 10 x64 version 1909
  • Window 10 x64 version 1903
  • Windows server 2008 R2
  • Windows 7 32bit Test made on a share offered by A) other machines B) from a Qnap nas, C) from same machine;
    Disabled also the firewall on machine executing Syncthing but nothing change.
12

Did you try just using \\servername instead of the fancy question mark unc stuff?

13

Yes: if I use your form, for example:
\\servername\sharename\folder Syncthing functions correctly, is the
\\?\UNC\servername\sharename\folder
form that does not work anymore.
Latter form is used and supported by Windows to permit to have filename paths with a lenght more than 250 characters.

14

I think the longer path support is now handled by go itself, so the extra prefix is not actually needed. Also, the prefix used to be \\?\ without any UNC stuff.

15

Hmm, but the fancy stuff is still working though. I do not use this normally, but I have just tested again for the sake of it:

image
image1209×333 27.1 KB

@cmarsura Does the problem happen with all UNC paths, or only with those longer than 250 characters?

16

The problem happens also with path lenghts less than 40 charecters.

However this issue is strange enough: I see you have tried with the 1.10 release candidate so also I tried it by enabling ‘Upgrade To Pre Releases’ in advanced settings.
With this version the problem does -not- appear anymore; problem disappears also if I upgrade directly from 1.9 to 1.10 rc2.

It seems appearing only with the stable 1.9 version.

1 Like
17

1.9 has the Windows specific FindFirstFile stuff for case resolution, maybe that doesn’t like unc paths. 1.10 is back to usual Go APIs that turned out to be faster anyway.

2 Likes
18

So I think you can put a stone over this thread.
Thank you for attention.

Best regards. :+1:
Carlo

19

Just in case you prefer to stick to stable releases, go to the Advanced Configuration and enable Case Sensitive FS for the affected folder. This will revert to the pre-1.9 behaviour and make the UNC paths work properly. You can deactivate this option later once a stable release of v1.10.0 comes out.

20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.