How should ST behave in the given example?

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:

  1. Fix whatever is causing database corruption, as it shouldn’t corrupt by itself.

  2. Delete all the files on the corrupted node and let it sync fresh.

  3. 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.

  4. 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.

@AudriusButkevicius,

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 :wink:

1 Like

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.

2 Likes