Most importantly, I fixed the signing problem lots of people were having. Local discovery is not fixed though (yet). You can find the full changelog with the download.
It may take a while until it’s available on Google Play, but you can download from my Github in the mean time.
@calmh Could you give me permission to post to the Announce category (and maybe move this topic, too?)
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.
This is probably because the sdcard is formatted as fat32, which doesn’t support unix permissions (I totally forgot about that).
Are those the same permissions as on your sdcard? I get drwxrwx--- root sdcard_r there, but that might be because I’m rooted.
As did I 
I’m running CM 10.0
Perms on my sdcard:
d---rwxr-x system sdcard_rw
and on directory being snched:
d---rwxr-x system sdcard_rw
Yeah, so syncthing tries to set the permissions it gets from the other nodes, fails silently and syncs the (unchanged) permissions back to the other nodes.
@calmh Can we do an explicit test if the repo has fat32 fs? Or check if permissions were applied, and not sync them if it fails? Otherwise, I’d add a “no permissions” flag to repos.
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.
This seems to be the same basic problem as #236 (syncthing tries to write data, fails silently, and syncs the unchanged data back).
Maybe yes/no. 
There seems to be several bugs/issues affecting this right now;
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… 
My understanding of permissions (and how they are synced) is limited, so I’m not quite sure what you are saying. Unless you know any way I can help, I guess I’ll just wait until you fix it
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.
Other problems are linked to the fact of not supporting all attributes, for instance the ‘Encrypted’ flag if a replica of the file in not considered as by other Windows nodes.
I suppose you could anticipate those problems and declare them at creation time, before trying to sync them?
I don’t think I got that, what was the problem to anticipate?
Ok I think I could implement that. It should be a per repo flag, right? (not per node).
Should it also affect other attributes, or only permissions (and how would you name the flag?)
I would suggest a per-repo flag called syncPermissions or something similar, defaulting to true so one could say
<repository id="..." directory="..." syncPermissions="false">
...
</repository>
in the config and have a checkbox “[x] Sync Permission Flags” or something in the UI.
Might be a little bit hairy to implement since the checks for and setting of permissions is a bit spread out.
This sounds like a sensible approach.
Ok here’s what I have so far:
Extra per “class”/per file documentation would be nice, and a sentence or so about each function (and maybe parameters)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.
Dude…
But that means if I set permissions 700 on linux, it will always be set back to 666 if synced with Android. Is that expected behaviour?
Sorry, just some friendly suggestions :s
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.
Ok I’ll do it the same way then. Although a flag would be cleaner imho (but maybe we can do that at some point in the future).