Version 0.8.10 includes a new “Ignore Permissions” flag per repository. The primary use case is for filesystems that do not support permissions, such as FAT, or environments where changing permissions is impossible.
When the checkbox is checked for a given repo files originating from this node will be announced with the “no permission bits” flag. Other nodes will use whatever their default permission setting is when creating the file. Nodes running older versions than 0.8.10 will use the permission set 0666 (read/write for everyone).
Currently we have to set “Ignore Permissions” flag by hand. But syncthing can do this automatic, isn’t it? Or display one warning if FAT filesystem found?
We can make a best guess at repo creation (and should do so), but it’ll never 100%. For example, if a FAT filesystem is mounted in a subdirectory somewhere under the repo root, this will be tricky to detect. Or at least a lot of work that won’t be useful in 99% of setups, so a manual component will remain…
The main point is to avoid an issue when syncing to filesystems that don’t understand permission bits. What happens when you sync between for example an Android phone and a Linux computer with this off (or on v0.8.9-);
Create file test1 on Linux, permissions 644.
Files gets synced to Android, synthing sets permission 644 successfully. Android uses a FAT filesystem where permission bits don’t map that well to Unix permission bits. What actually happens is that the read only bit is cleared.
Syncthing scans for changes on Android, gets the permission bits 666 for the file in question. Notes that this is a change, publishes the new version.
Linux updates permissions of test1 to 666.
Unwanted. If we check the “Ignore Permissions” checkbox on the Android side, the following happens;
Create file test1 on Linux, permissions 644.
Files gets synced to Android, synthing does not set permission bits explicitly. File gets read-write permissions per default.
Syncthing scans for changes on Android, gets the permission bits 666 for the file in question. Notes that this is changed from what the index says, but that the “Ignore Permissions” checkbox is set. Ignores the change.
The text you quote about sending permissions is about what to do when a file/directory is created Android-side.
Create file test1 on Android, read-write permissions.
Syncthing picks up the change, notes the “Ignore Permissions” checkbox. Announces the file with the “No Permissions Present” bit set in the index.
Linux gets the change, creates the file, does not change permissions from whatever was set by default since the “No Permissions Present” bit was set in the index.
Linux rescans, sees perhaps a difference in permissions from what is expected, but the “No Permissions Present” bit is set on the file in the index, so we ignore the change.
The default permissions 666/777 that you quote are to avoid completely breaking compatibility with older versions that don’t understand the “No Permissions Present” bit and would set do a chmod(0) on the file.
Note that if you change the contents of a file on Linux and also the permission bits, this change will be published. Other Unixes will pick up both changes, but the Android side will ignore the permission change (if “Ignore Permissions” is checked).
I chose Android to represent the less capable side here. That’s not really the point, but the underlying filesystem. The Windows version of syncthing already contains some code to handle this in all cases, irrespective of the underlying filesystem. Although setting “Ignore Permissions” there will stop the propagation of read-only bits, which we otherwise do.