Yeah, I guess the only safe way would be to require the user to simply update their ignore patterns. That’s another reason why this would be a breaking change after all… Similar to requiring changing all single dash command line options. I guess the problem here is that with the command line options, Syncthing fails to start completely, while in this case, it would start and work normally but the old ignore patterns wouldn’t work as expected.
What happens if in v2 ignore patterns always use / for directory separators and Syncthing internally translates / to \ for Windows paths? Then ignore patterns can be platform agnostic and consistent?
This would be preferable to me, but I’m not sure how to automagically convert ignore patterns. Does this logic work?
if platform=Windows convert \ to /
Would this totally confuse Windows users and send them completely off the deep end?
How did we get here, anyway? Did somebody have a patent on using / for directory separators when Bill Gates chose that for command switches in DOS 1? (There is an alternate explanation that I will just leave to the reader.)
So, my 2 cents on this issue…
- Ignores are tricky to migrate in general, because our system is too flexible with includes and whatnot. It has been a long standing issue for that reason.
- Any migration we do needs to be either 100% or 0% and nowhere in between and no guesses. Messing with peoples ignore patterns and getting it wrong is guaranteed to cause data loss or data leakage or both and is unacceptable.
- For a 2.0 upgrade, if we can’t safely migrate a given folder the only thing we can do is stop it with an error – “unsupported feature in use, manual upgrade required, read the release notes”. That would suck, but suck less than losing data.
- In this case, having #include directives in the patterns seems like it would be a failure condition as I see no way to handle it safely. Saying “you need to shut down all your devices at the same time, migrate them all to v2 in isolation, then bring them all up again” is not acceptable imho…
- All of this seems annoying and out of proportion to the gain to me, especially since the end result is something that seems like it would leave most casual Windows users scratching their heads and writing incorrect ignore patterns for the foreseeable future… But I don’t run that platform and won’t block the change for those who do if you all decide it’s the correct direction and manage the fallout properly.
What you could do instead is make a new, improved, ignore format/system and add it in parallell. (Maybe migrate the trivial cases and leave the non-trivial ones alone and add a flag on the folder * Uses deprecated ignore system or something.) (This doesn’t have to be 2.0 since it would be backwards compatible.)
3 Likes
Looking at this again, I agree that it’s likely way too much hassle just to allow using the few special characters literally (which I think are basically [] and {}, as the others, e.g. ? or * cannot be used in Windows filenames anyway).
What do you think about allowing for some other way to escape characters under Windows? That would be backwards compatible and basically fix the main issue.
2 Likes
That seems way less problematic at least, but you may have to negotiate with the somewhat annoying glob package we use. (n.b. you cannot just slashconvert the patterns and call it a day since foo/[abc]ar on non-Windows and foo\[abc]ar on Windows mean two different things today)
We have a lot of non-expert users and changing the Windows path separator to a non-standard will almost certainly cause a ton of problems. Despite the fact that \\ is used in Windows in the registry, I’d say that is the exception and even people who are Windows techies may never have come across it here.
This change would violate the principle of least surprise and IMO it is a bad way to fix the problem with escaping characters for Windows. I would say if we fix this - and I do think it should be fixed - we should use |. I have seen | used as an escape character before, if it’s in the docs people might even find it, and I don’t think it will cause any side effects.
3 Likes
What’s the need to translate the paths internally? Windows (and all version of DOS with directory support) supports both / and \ as path seperators. You can even mix them in the same path, like C:/Users\mixing/Documents\file.txt.
The reason why backslashes are often preferred to forward-slashes is because forward-slashes often conflict with command switches (as you seem to already know), but Syncthing uses double-dashes for switches, so not a problem in this case.
Did you mean “revamping”?
PR https://github.com/syncthing/syncthing/pull/10058 allows Windows users to use the pipe symbol (|) to escape the metacharacters. It also allows Windows users to use the backslash character, by adding #escape=\ to the top of the .stignore file. This will allow the same file to be used on any platform.
Hi!
I just learned that Synctrayzor is not compatible to 2.0.
I’m really sad about this because I use only Synctrayzor on all my devices. It seems it is only because of the - and – changes. So Id kindly ask to keep compability towards Synctrayzor. I know it is an abandond project 
. Thanks in advance!
1 Like
I am in the same position so I have started using syncthing tray. It will start Syncthing and keep it all hidden off the screen. I’m still getting use to it and have decided that the remote devices will remain on v1 / synctrazor until either v1 becomes unsupported or the device is replaced and I will then move over to Tray.
It does require a change in thought and setup to use Tray and with some tweaks, could be very useful.
It’s worth a try
1 Like
Maybe someone could make a PR for synctrayzor if it’s just a matter of replacing one dash with two
Forking is the only option:
Its good to know that Windows will accept either from programs, I did not know this (or hadn’t noticed, and I’ve worked with MS-DOS since MS-DOS 3!).
This works in Windows Explorer (GUI) or when requesting a file from the filesystem, so may not be a relevant concern in this discussion about the Syncthing Ignore File Format.
For the record, using / in place of \ will not work consistently at the command line in Windows 10 or earlier (cmd.exe or MS-DOS’ command.com).
Depending on the command, using
/in place of\in a fully-qualified path may work, or will result in an error message,Invalid Switch -. For example,cd c:/usersor evencd /d d:/usersseems to have no problem, butdir c:/usersdoes not work.
I am looking forward to seeing one-way backup and selective synchronization.
For one-way synchronization, we can synchronize only add and modify operations, but not delete operations. It can realize backup of mobile phones and other devices, just like many network disks do.
For selective synchronization, OneDrive has implemented it several years ago and regards this feature as an important feature. Maybe Syncthing can only synchronize the complete file list in the database, but set some files to not be transferred to the device by default, which can save a lot of storage space. Of course, at least one real copy needs to be kept in all nodes, which may be the most difficult part of implementing C/S architecture in P2P nodes.
In the current state, for novice users, if they want to implement “backup” instead of “sync” and click the “Override Changes” button without reading the document, it usually leads to a tragedy. Maybe it would be better to directly provide a function similar to backup.
1 Like
One of us is missing something: I don’t think either of those features are planned by the Syncthing team. But I don’t speak for them, so I’m ready to be wrong.
3 Likes
This might go without saying, but I hope these two changes makes the include directive move from being ignore-specific to being usable everywhere.
Having a top-level include would likely be the best cure against the mess of needing to recover whenever occasionally accidentally starting syncthing without having the location of the true configuration (under version control) accessible. Every time this happens I’m wishing to contribute a patch to slightly delay removing all sync history, then never actually putting that time on syncthing. Not after the hour or so needed to be spent on sudden unplanned conflict resolution.
As for .yaml you have my +1. That format is what I have used for my config from day one. The first thing I did when seeing .xml was to suffix the original generated file with .j2 and hack up a script to pull the variables I cared about out of easier files. Having an actually readable config has likely saved me a few time, but it sure would be lovely to be able to ditch that need of a custom local hack.
1 Like
How about taking 2.0 as an opportunity to require e.g. a --json-flag to syncthing cli for having it operating as it does today? This would allow adding human readable output of the most crucial information.
After loosing the guy who made the Android version of Syncthing (or is there any new Android App working with Syncthing?), I need to to keep Syncthing 1.28.1 on Android up and running with my PC, otherwise I won’t need Syncthing at all. So will the Syncthing 2.0 and higher on PC still be compatible with the 1.28.1 on Android?
I think there will be a Syncthing for Android 2.0 at some point as I need this too 
.
3 Likes