[GH-ISSUE #387] Conflict resolution w/ guaranteed non-loss of data #1272

Open
opened 2026-03-14 00:49:29 +03:00 by kerem · 6 comments
Owner

Originally created by @JGKle on GitHub (Apr 3, 2023).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/387

Profiles configurations have 3 options for conflict resolution:

  • Server Wins
  • Outlook Wins
  • Automatic

I would like to request some option that's "guaranteed" never to inadvertently overwrite modified data. i.e:

  • Manual: Shows a user prompt if there's a conflict, letting the user know that a conflict occurred and letting them select the one to keep. This seems like the ideal solution, but since it involves new UI, may be more work than you're willing. If that's the case, an easier approach could be:
  • Duplicate: If there's a conflict, create a new separate item so that both modified versions are retained (i.e. named original-name.CONFLICT).

Although I've tried to be deliberately careful never to update the same item from both ends, I still end up suffering data loss from time to time. i.e. I edit a reminder's description, then when I come back to that reminder, the edits are mysteriously gone. One time I tracked this to an issue on the server, where it erroneously reported an error 500 (even though it had actually synced), so on subsequent sync, CalDAVSynchronizer saw updates on both ends. Other times I was working on a 2nd machine, and simply thought that the 1st machine had finished syncing, but it hadn't due to poor network connectivity. In any event, the point is that there will likely always be occasional edge cases, so it would be great if there were a conflict resolution option that will definitively refuse to overwrite modified data.

Originally created by @JGKle on GitHub (Apr 3, 2023). Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/387 Profiles configurations have 3 options for conflict resolution: * Server Wins * Outlook Wins * Automatic I would like to request some option that's "guaranteed" never to inadvertently overwrite modified data. i.e: * Manual: Shows a user prompt if there's a conflict, letting the user know that a conflict occurred and letting them select the one to keep. This seems like the ideal solution, but since it involves new UI, may be more work than you're willing. If that's the case, an easier approach could be: * Duplicate: If there's a conflict, create a new separate item so that both modified versions are retained (i.e. named `original-name.CONFLICT`). Although I've tried to be deliberately careful never to update the same item from both ends, I still end up suffering data loss from time to time. i.e. I edit a reminder's description, then when I come back to that reminder, the edits are mysteriously gone. One time I tracked this to an issue on the server, where it erroneously reported an error 500 (even though it had actually synced), so on subsequent sync, CalDAVSynchronizer saw updates on both ends. Other times I was working on a 2nd machine, and simply thought that the 1st machine had finished syncing, but it hadn't due to poor network connectivity. In any event, the point is that there will likely always be occasional edge cases, so it would be great if there were a conflict resolution option that will definitively refuse to overwrite modified data.
Author
Owner

@aluxnimm commented on GitHub (Apr 5, 2023):

You are right. That manual conflict resolution is lacking atm and needs to be addressed. No timeframe yet since that needs some work.

<!-- gh-comment-id:1497439783 --> @aluxnimm commented on GitHub (Apr 5, 2023): You are right. That manual conflict resolution is lacking atm and needs to be addressed. No timeframe yet since that needs some work.
Author
Owner

@JGKle commented on GitHub (Apr 5, 2023):

Sounds good :)

As a quick follow-up, if "full resolution" requires a fair amount of work & thus might take awhile, a potential even easier quick-and-dirty solution, to prevent further data loss in the interim: the option to simply "Fail." If selected, and if a conflict is detected, it will simply refuse to sync that item (and log the error). Then the user must manually delete the conflicted item at one end or the other (which would let the sync come from the other end)

Obviously not quite as seamless as the others, but potentially an easier solution for the moment, just as a quick way to put an end to the data loss? :)

<!-- gh-comment-id:1497606067 --> @JGKle commented on GitHub (Apr 5, 2023): Sounds good :) As a quick follow-up, if "full resolution" requires a fair amount of work & thus might take awhile, a potential even easier quick-and-dirty solution, to prevent further data loss in the interim: the option to simply "Fail." If selected, and if a conflict is detected, it will simply refuse to sync that item (and log the error). Then the user must manually delete the conflicted item at one end or the other (which would let the sync come from the other end) Obviously not quite as seamless as the others, but potentially an easier solution for the moment, just as a quick way to put an end to the data loss? :)
Author
Owner

@Kansai53 commented on GitHub (Jun 8, 2023):

I hve data loss often, and after reading this I am pretty sure it is because of conflicts (my internet isn't reliable), and I see logs with "1" on both ends. Sync software like SyncThing uses the second idea, where if there's a conflict it just makes a duplicate --CONFLICT file to guarantee data is never thrown out with out the user knowing about it. Seems like it would be pretty easy to just create a new duplicate entry like this? Would be really great, if it were as simple as that to make sure data no longer is lost

<!-- gh-comment-id:1583337992 --> @Kansai53 commented on GitHub (Jun 8, 2023): I hve data loss often, and after reading this I am pretty sure it is because of conflicts (my internet isn't reliable), and I see logs with "1" on both ends. Sync software like SyncThing uses the second idea, where if there's a conflict it just makes a duplicate --CONFLICT file to guarantee data is never thrown out with out the user knowing about it. Seems like it would be pretty easy to just create a new duplicate entry like this? Would be really great, if it were as simple as that to make sure data no longer is lost
Author
Owner

@Ricent82 commented on GitHub (Sep 8, 2023):

I wish there was a way to solve this for now, at least an option to make it refuse to sync when there's a conflict. I missed an appointment because I changed the date one one computer then later edited the description on another, and I guess the description edit silently overwrote the date change.

<!-- gh-comment-id:1712244534 --> @Ricent82 commented on GitHub (Sep 8, 2023): I wish there was a way to solve this for now, at least an option to make it refuse to sync when there's a conflict. I missed an appointment because I changed the date one one computer then later edited the description on another, and I guess the description edit silently overwrote the date change.
Author
Owner

@Ricent82 commented on GitHub (Dec 16, 2023):

Just missed another meeting due to a conflict nuking data. Kindof wondering if this is an abandoned project due to the lack of responses on here, & seems like no motion in 8 months :(

<!-- gh-comment-id:1858839892 --> @Ricent82 commented on GitHub (Dec 16, 2023): Just missed another meeting due to a conflict nuking data. Kindof wondering if this is an abandoned project due to the lack of responses on here, & seems like no motion in 8 months :(
Author
Owner

@JGKle commented on GitHub (Jan 8, 2024):

Ughhh it just happened again - I wrote a bunch of content in a calendar description, saved, came back an hour later to make an addendum, and the entire description was missing. No other computer was on, so this definitely wasn't a real conflict. Checked the logs - it first had a sync timeout:

2024-01-07 21 24 02


...Then 3 minutes later, it retried to sync, saw a change at both ends, and decided to nuke all of my changes:

2024-01-07 21 24 17

Again, no other PC was even on.

<!-- gh-comment-id:1880404951 --> @JGKle commented on GitHub (Jan 8, 2024): Ughhh it just happened again - I wrote a bunch of content in a calendar description, saved, came back an hour later to make an addendum, and the entire description was missing. No other computer was on, so this definitely wasn't a real conflict. Checked the logs - it first had a sync timeout: ![2024-01-07 21 24 02](https://github.com/aluxnimm/outlookcaldavsynchronizer/assets/1877409/2a5e4d48-fc8d-47eb-9c28-1c711dec2654) ---- ...Then 3 minutes later, it retried to sync, saw a change at both ends, and decided to nuke all of my changes: ![2024-01-07 21 24 17](https://github.com/aluxnimm/outlookcaldavsynchronizer/assets/1877409/9d3728ee-ff23-485a-9f57-d0792ef3dcaf) Again, no other PC was even on.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/outlookcaldavsynchronizer#1272
No description provided.