The problem here is that you are not wanting a 2 way sync initially.
⌠In your scenario, you might be able to temporarily make A (and maybe B?) a folder master. Let it sync with C, then hit "override changesâ to force C to mirror A. Then remove the folder master status.
You can add a âMasterâ share with A as the master on each device, this is in addition to the initial share using the same directory.
Once C is in the same state as A and B add it to the original share and remove it from the Master share.
Yes, the first time C joins to the sync should be a mirroring(a special situation because of A and Bs actions during Câs offline status). However we are talking about files that are know to be deleted by A and B. C will put those files back in. A and B do not want those back because they decided to delete them.
Edit: I said âmirroringâ but it should be mirroring + C sending files that are new or changed (which do not match the hashes of the deleted files on A and B).
I can see there being a reasonable use case for an option when accepting a share to âOverride Existingâ but I would not suggest this as standard behavior.
Yes this can work only if everyone is aware of what is going on and in stable communication.
Or C is able to select a device as master on its end, which is something we do not have now.
We have âPauseâ button, there can be similar thing on the share menu where it says âmatch othersâ something along those lines. This can be a mirroring+sending new/updated files (not the deleted ones)
The biggest isssue with this âmasterâ approach is that C will also loose all the new and updated files on its end which goes to a similar situation calmh mentioned. C might have changes while its offline. But if no changes were done by C, then it can work
Being deleted is just one phase in the complicated life cycle of a file. It can come into existence again in the next moment.
The database is what we use to keep track of this. When that gets lost on C, you basically have the situation of A and B saying âthis file was deleted yesterdayâ and C saying âI can see this file exists now, but I donât know itâs historyâ. The safe choice is to keep it. It may not be the same file that A and B deleted, itâs just something that happens to share its place in the file system.
So when there is doubt about in which order things happened, we decide in favor of the file existing. This will be right in some cases, wrong in some cases. In any case itâs preferable for the user to delete an unwanted file rather than recreate an incorrectly deleted file from scratch.
That is great but that is not what A and B wants, and C is definetely achieving this (putting the deleted files back) unknowingly.
The thing is that in these kind of cases it can get super complicated to get this shit back in track because the users have to go back historically remember and figure out all those files and put the state of their repo just before C joined in. And I can guarantee you that in %90 of the cases most users wont even know that they got their deleted files back unless they have super tiny repos with couple files, enough that they will see that again and start hitting their heads against the wall for sudden appearance of the deleted files. Only goodness knows how many times I experienced that myself.
I really hope that the devs will consider putting an option (by default it is off) like âprefer deletesâ which will make ST to prefer deletes in these kinds of cases, if possible.
thanks
Weâve given you multiple cases where your proposal would cause data loss. You keep repeating your scenario of 3 peers as itâs the only possible scenario and havenât considered anything else, even the scenarios which weâve provided in this thread.
There is not much reason to discuss this anymore, as itâs not about what anybody wants, itâs about not having data loss, and we are definately not introducing an option which allows data loss.
You have four options to work around this:
-
Fix whatever is causing database corruption, as it shouldnât corrupt by itself.
-
Delete all the files on the corrupted node and let it sync fresh.
-
On the corrupted node, unshare the folder with everyone, create a new folder on non-corrupted peers pointing at the same location, but a different location on the corrupted peer, let it reuse files from the old directory which is now unshared.
-
Enable master mode on one of the non-corrupted devices before the corruoted one re-joins. Override any changes introduced by the corruoted node from the master.
You keep repeating this attitude through out the forum topics, you should fix the undertone of your replies before fixing bugs in this software. You have no reason to join conversations you do not like. You actually have not brough up anything valueable to my discussion. Also you did not bring up a single case, others did and I did. You seem to claim ownership of those cases by saying âWeâve given you multiple casesâ. All you do is lame power tripping here. All you said and kept repeating was that it is a âconflictâ and that was the end of the discussion. However I now see that you have a âconflictâ with the users of this application. On the otherhand @calmh was professional and listening and answered with great care. The users are not beggars who are trying to chip away your fortunes. We the users make your software something of a value, without the users this software means nothing.
I never demanded anything, and I never said that is what everyone wanted. All I did was to bring up a case where your great ideas fail to achieve what is needed.
@calmh, please close the thread hopefully keeping this last reply.
Huh? He was (politely) explaining to you where your proposal is lacking, and why it will not be taken forwards. He even gave you a bunch of options to work with.
Without the developers it means even less
I am sorry, but we donât seem to be getting anywhere with this discussion, as the posts seem to be repeating themselves in what they mean, therefore someone has to be the bad guy, put the foot down as otherwise we can keep discussing this until the cows go home.
I perfectly understand what you want and understand why you want it and it makes perfect sense, itâs just that itâs not a safe feature (and others provided usecases explaining why) therefore I donât think we should have it available (nor as far as I understand Dropbox et al provide this prefer lossy
conflict resolution), and as a result of that, Iâve provided workarounds which achieve the same behaviour.
I am sorry if I sound like an ass, but I am just trying to save everyones time.