Are there any plans to drop the beta/testing label?
From my experience the feature is not production ready.
I’ve been using it and posting about issues with it, post which goes unanswered.
Apparently, there are very few people from the community using it and issues cannot get traction.
2 Likes
Personally, I’d love for the bug
to be fixed before labeling the feature as “stable”. If the user is unfortunate enough to get hit by this one, there’s literally nothing they can do to work around the problem.
2 Likes
For what it’s worth, my Windows 11 has no problems handling files with reserved names using the Windows Explorer.
In fact I don’t even need the \\?\ stuff I used above, it seems like the reserved names are hardly reserved at all. I can create a file called LPT1 and save stuff to it using Notepad. What doesn’t work is to directly create a file named like that in Explorer.
So maybe the correct answer here is just to remove the restriction for encrypted folders, as suggested, and/or make it configurable in general. (Yes, I understand previous versions of Windows may act differently, but this is apparently the direction we’re heading in and it’s somewhat of an unlikely corner case already.)
If this is also the case for Windows 10 and Windows Server 2012, i’d say that we should lift the restriction.
No this is new in 11, Windows 10 requires the backslashes trick and just silently fails to do stuff with the items in Explorer (including deleting them).
I think it’s reasonable to lift the restriction if Syncthing is able to create those files. Encrypted folders are a more advanced feature and we can expect users to be able to delete folders via powershell/cmd in this rare case.
Same thing for path length restrictions.
This is still a problem, e.g. if you set up a Receive Encrypted folder on a family member or a friend’s computer. If something happens and you’re unavailable, they could easily be left with folders that they cannot delete. For the record, this is actually my use case for Receive Encrypted folders.
If Windows 11 can delete those folders through the GUI interface, that’s indeed great, but it’s going to take a while till it overtakes Windows 10 (largely due to its ridiculous system requirements). At the moment the adoption rate is rather poor (see https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide). I’d give it at least 3+ years if not more to gain more market share than Windows 10. There’s also no guarantee that it won’t flop like Windows 8 did, and we’ll have to wait for Windows 12 to become the real successor 
.
I’d keep in mind, still, that a path component of an encrypted file is
- between one and 200 characters long
- randomly of the base32 character set
so there’s effectively 32 + 322 + 323 + … + 32200 = 32201 - 1 possible values for a path component. There are 24 reserved names, so that’s about 7·10-300 % chance of any given path component being bad, as I understand it. With enough users, enough files, and enough luck, obviously, someone runs into it. And maybe there’s some factor that makes path component lengths not particularly evenly distributed (it’s a factor of the original name, after all), but I’d but surprised if it’s that common to be a blocker.
It seems more like it happened once out of random chance and now everyone’s worried about it.
1 Like
Just a dumb question but could we add a fixed non-base32 prefix to path components like e.g _ ?
Also: wouldn’t the path length alone be enough to cause problems with folder deletion?
Yeah, I understand that the problem’s very unlikely, yet someone’s already encountered it, so… 
.
In this case specifically though, if I set up a Receive Encrypted folder on someone else’s computer that I’ve got no direct access to, I’d just like to be extra sure that everything will always be able to sync no matter what. Also, in the rare case I do get hit by this error, is there anything that can be done to recover? It’s essentially a game over, isn’t it?
Long paths can be easily deleted, because you can still rename them using the Explorer GUI. That’s not the case with restricted filenames.
Long path names are a wide-spread problem, not necessarily on windows but it came up a few times already. And I don’t quite remember now, but I think there was another change to the naming scheme I wanted to make to handle some fringe case. Yet another reason to still call it a beta thing: Gives us more leeway to break things (of course not lightly, just if benefits clearly outweigh the annoyances).
1 Like
@imsodin this one?
https://github.com/syncthing/syncthing/issues/7987
@tomasz86 is it really that easy? The user would still need to figure out which elements to rename in the folder structure. At least for not technically inclined users it’s just as bad.
1 Like
It’s not really the same, because with long paths, Windows literally tells the user the problematic files with a possible solution, e.g.
so the user at least knows what they need to do. In the case of restricted stuff, there’s nothing like it, with the user essentially being left in the dark.
Of course, it would still be nice if the paths could be shorter to avoid this kind of situations altogether 
.
On my end, I’m hitting two different bugs with the untrusted devices: