The need will never die: ignore local changes for "Receive Only" folders

Support
21

Yeah, I meant something that could be suggested when the problem comes up on the forum, or even something to add to the FAQ, as this particular case of one-way synchronisation seems to be quite popular (regardless of all the different opinions about it :sweat_smile:).

22

A conflict file is created and creates confusion about which is the main file in this setup. Leave a system unattended, and many many conflicts, from many files pile up over time, with no automatic way of cleaning up (e.g. not handled by versioning cleanup).

But more importantly, if grandma or a weekly media-server-scan touches a file, after I also touch a file, then we both go online, it will make a conflict file and I leave its local file as the “main file”. I can’t set it up such that mine is treated as the truth.

calmh is just shiftlessly coming up with edge cases in his favor of handwaving the issues/needs I reveal. (e.g. “infinite loop fighting with some other program” – what other program runs that often on all your files? It would happen once a week not once per cpu clock – “infinite loop”… jeeze… A similar “infinite loop” is also what happens when 2 users take turns editing the same file, you intractable frustrator)

23

“You can get that behaviour already though by configuring the folder to not create conflicts, it’s just not default.”

If folder A is configured to not create conflicts, and is set to “receive only”, and edits a file, and folder B is synced with A and set to “send only” and edits a file after folder A has edited a file, and A and B go online, then there is a conflict. So then what happens? Does syncing just not happen?

We just need a scenario where I can ensure that a –transfer– occurs, no matter what, from my machine to my backup machine, and is treated as the main file. It’s a simple need that common people have :slight_smile:

24

If you tried to show evidence, you’d see it behaves just like you want: Of course a valid remote change in conflict with a local change in a receive-only folder will always win. As everyones telling you, it will not block syncing and get you the file you want.

25

I did try things… I came here after getting conflicts. I was getting asked to resolve each one and pick which one to keep. Other threads have been made about this too.

“A valid remote change in conflict with a local change in a receive-only local folder will always win” - This sounds wrong / unintuitive to me. But if it is true, then disabling conflicts for the local receive only folder, solves the question in the OP, and all the previous threads. So why did we have to argue for 20 pages (and other threads) to get to this point? :sweat_smile: (would be nice to mention it in a faq, behind as many warnings as you want)

(BTW, please point me to where to “disable conflicts”. Is it this? “Yes, set maxConflicts to zero for the folder, in advanced config.”)

26

I don’t know, I think we quite quickly told you that what you described as the problem (“the whole chain stops”) just doesn’t happen.

And to be clear about conflicts, not that I think you really deserve or care about the explanation but for potential future onlookers,

  1. A local modification in a recv-only isn’t a conflict, it’s just a change. But it’s a change that marks the file “invalid” (not to be sent to other peers).
  2. Any other change that comes in for that file in the future is a conflict, because that version isn’t a descendent of the locally changed file.
  3. That conflict will always be resolved in favour of the new version, because valid wins over invalid. (And newer wins over older, if they were both valid for whatever reason).
  4. The locally changed file then gets moved to the conflict copy, or not, if you disabled that as above.
3 Likes
27

Then what were you talking about not wanting to implement the feature, if the feature was already implemented? “I get conflicts, therefore my automation is blocked” was my observation…

Ok so to clear up confusion:

  1. UX wise, I don’t think common users ever understood that a local modification in a receive only folder behaves different to one on a non-receive-only folder (that there is this invalid state. which btw the word “invalid file” would lead me to think that this file is broken or not received properly)

  2. Great. This again is confusing UX wise / would’ve never figured that out. Would have thought instead that files don’t come in if there is this mysterious forever conflict file blocking the way.

  3. Ok. “Newer wins over older” is concerning though, but, as you guys said “newer wins over older, unless it’s a receive only folder, in which case the older remote always wins” – Is this correct?

  4. I would have intuited that if you disable conflicts, then the local file never changes, but you’re saying that it gets deleted and replaced with the file that wins (the remote file in case it’s a receive only folder). Awesome.

So thanks a lot for clarifying, there’s no way an average user would have had a clue about even half of that behaviour. Being the best p2p sync tool means your ux gotta deal with many many different users. :wink:

28

The “feature” only works if your source file is modified. If on the receive only side you fill the file with garbage, and you don’t modify it on the send-receive/send-only side, then the file stays filled with garbage.

1 Like
29

I think it’s valid wins over invalid, then newer wins over older.

3 Likes
30

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.