- Syncthing v0.10.23 master node - Linux
- Syncthing v0.10.21 non master node - Android
Override Changes alert pops up on every folder scan on the v0.10.21 android device
- create new folders on each machine
- add new document into master node folder
- scan folder on android
- wait for transfer
- scan folder on android
- Override Changes alert pops up on master node
Im guessing this is not normal or intended?
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.
How come Android doesn’t sync mtimes? It does support them?
Not on the sd card it doesn’t.
Never knew that!
Here’s the bug report I believe, Google have accepted it as an internal bug as of July last year but nothing yet it seems.
As far as I know, it is not just in the sd card. Keeping two androids in sync with syncthing is problematic, regardless of where you put files:
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.
https://github.com/syncthing/syncthing/issues/837 was that.
Perhaps we should reopen that.
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.
I think you should just reopen it, with a good list of OS specific files (rather than .svn et al which as not specific at all)
Edit: I actually reopened it.
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.