Works pretty well, with one fairly grievous bug: it (without me selecting the “make master” checkbox) changed all the perms on the other nodes for the repo I was synching, meaning I couldn’t access any of the directories in that repository on the other nodes.
I tested by isolating all of the nodes bar one, resetting the perms (755 on the directories and 664 on all of the files) and then resynched with the Android app. Once the sync was complete, the permissions on the node reverted back to read only: d---rwxr-x 2 jason users.
I’ve checked the config file, and ro="false".
Manually resetting the permissions and removing the Android app restored the correct perms across the cluster.
Right, so what happens currently is it syncs a file, verifies the hash etc, then sets the permission bits and modified time (ignoring the errors if it fails, because what is there to do about it?), then marks the file as up to date in the index. The next scan, it sees that the permission bits or modified time is different from what the index said, and interprets it as an update.
I don’t think there’s a clean workaround for this. We could of course handle the errors better, but you still have the situation when syncthing starts up and compares the index to the actual repository contents.
This will probably need an ignore-permission-bits option per repository.
Maybe yes/no. There seems to be several bugs/issues affecting this right now;
#236, because on Windows a read only file is also protected from deletion (as opposed to on POSIX file systems)
#237, where file permissions are not synced if they are the only thing to change, since the unchanged-check is stupid enough to only check modified time.
In fact, #237 should be good for you because it would make it more lenient to changes in just permission bits. On the other hand, FAT filesystems (if I remember correctly) only store modification times to a two second precision, so any files with an odd modification time would be resynced in the other direction when the timestamp doesn’t match any more. Being cross platform sucks…
Summarizing; there are bugs, but even with those bugs fixed things won’t work if the filesystem doesn’t allow changing permissions. That will need an ignore-permission-bits feature which isn’t there currently.
I’d suggest not having such a bit and simply sending the permissions as either 0666 or 0444 depending on whether the read only attribute is set, and locally ignoring permissions or translating as above when syncing. It already does something very similar for the Windows platform.
Only if you change the file on Android. Otherwise, when the Android instance gets the index, it “mentally” converts 700 to 666 and creates the file. When it checks for changes, it reads 666 from disk, sees 700 in the index and converts that to 666 and sees that they are the same. This is what happens with Windows instances right now. Changing a file that is a Unix executable on Windows will screw things up.