Override changes should not pop up on android as itâs not master.
But anyways, the problem is the fact that android does not support synching mtime, hence it always looks out of sync to the master, which then suggests to âoverrideâ androids failure to update mtimes.
Yes, the Android handling is difficult here. The request in the subject has come up before and Iâve decided against it, since silently and immediately overwriting changes on other computers is seldom the expected behavior.
I respectfully disagree here. I think there are scenarios where one wants to have changes overwritten by default (where, in fact, one is expecting that to happen whenever syncs take place), The Android case, where some apps that modify data that should never be transferred back to the computer, is one (i.e., this applies even if the mtimes issue was solved). Other scenarios, such as certain cases where transfering files for teaching labs, etc, are similar.
This would allow to us not to have to repeatedly click on the âOverride changesâ. In fact, I think that many users that rely on the âread onlyâ or âone-way syncâ of other applications are used to this, and would not shoot themselves in the foot.
To be more specific: this is not limited to your using an external sd card. Even if your android devices have no external sd card, if you want to sync files in a way that will be visible to other apps, you end up having to create directories under something called /sdcard. Thus, there are some special use cases where you do not run into trouble. But otherwise (i.e., if you sync files so another app can use them) you will run into trouble.
Thereâs a difference between a new change server side being propagated and whatever change I make locally being immediately and suddenly overwritten by the old version. If the latter is really the wanted behavior, it seems you could/should simply make the files in question read only for the users who are not supposed to change them?
"Thereâs a difference between a new change server side being propagated and whatever change I make locally being immediately and suddenly overwritten by the old version. "
Yes, you are correct. I was thinking about âa new change server side being propagatedâ, whenever anything happens in the server. I definitely was not thinking about it âbeing immediately and suddenly overwritten by the old versionâ (but Iâd rather have that, than nothing).
âyou could/should simply make the files in question read only for the users who are not supposed to change them?â
Two problems here:
a) That will not work (easily, at least) in crippled systems like Android;
b) I do not necessarily want them to be read only. Some applications do need to be able to alter some files. And some users might want to, too.
Which brings me back to the âlet the user decide if she/he wants the changes in the server to be immediately propagated, withouth further questions, to all âread-onlyâ nodesâ, like in âone-way syncâ settings of other applications.
Well I think this usecase isnât as obscure as you think. Often one wants to give friends and family a way to see your pictures and videos, but with no way of changing them. Syncthing with master folder on the local device does this really well. But because of less-than-careful users they often accidentally change the directory on their device. Manually overwriting this every couple of days is rather tedious.
Even worse, some operating systems create their own shitty special files and folders for thumbnails and such (I am angrily looking at you, OS X). But the latter should probably rather be fixed by creating OS-dependant default ignore patterns so that Windows machines donât sync files created by OS X and Linux, Linux ignores Windows and OS X files and so on.
BTsync does something similar, but they seem to ignore all files created by any OS. This seems like a good first step.
Agreed, I think the items proposed by Zillode in the last post and in https://github.com/syncthing/syncthing/issues/1055 are a good starting point. I have lost several hours running around with a thumbdrive to fix this in a <10 devices network with Windows, OS X and Linux machines. Iâll add my proposals over there, if it gets reopened.
I still think the other use case of automatically overriding changes from master folders (clumsy family members/friends) is valid, but has to be optional and off by default. With the new UI we can probably find a better way than simply adding another checkbox to the already cluttered interface tough.
Great, thanks! Iâll check what the exact files were that I had so much problems with with OS X and add them, but I currently donât have access to the affected devices. I believe @calmh and you are the only people who can open and close tickets on github
In case this helps anyone trying to use a âone-way syncâ without being prompted for overwritting changes.
I am now using a workaround via rsync or cp in the local machine; I am using lsyncd to have inotify detect changes and trigger the rsync (see http://code.google.com/p/lsyncd/) whenever there is a change in the origin.
This is an example of a situation with two âmastersâ and two âslavesâ:
I have a directory, call it D, that I want to sync between nodes M1, M2, S1, and S2. I want changes in both M1 and M2 to be transferred to all nodes, but I want changes in S1 and S2 to never propagate.
In ST, create folder Dm, and use ST to sync it between M1 and M2.
In your OS, create a directory, say Ds, in M1 and M2.
In ST, create folder Ds, and use ST to sync between M1, M2, S1, and S2.
Use lsyncd (or whatever you want) to rsync (or cp), locally, from directory D to directory Ds.
Iâve been using this set up for about a week (where S1 and S2 are Android devices) and things are working fine.
This works in Linux; I have no idea about other OSs, but probably similar workarounds exist. However, that said, I still think ST should provide the user the option of overwritting changes automatically, without asking questions. As I said above, I think many users are used to the âsync one wayâ or âmirror changesâ, or however you want to call this behavior: changes in the destination will be overwritten iff there is a change in the remote desginated as master/origin.