Bug: Files with newer timestamp are not chosen as version to be kept about onedrive

[abraunegg]

@JC-comp
I will look at this in more detail - however, please understand this .. your points are extreme edge cases.

Please note:

• When using --sync or --monitor the files online are the source of truth - thus the online file is the file to trust as correct and accurate and is the source for the local file copy. This is irrespective of if --resync is being used.

  • In the case where the file exists locally (but not in-sync) , and there is a timestamp mismatch, but the file hash is the same, the offending file timestamp should be corrected
  • In the case where the file exists locally (but not in-sync) , and there is a timestamp mismatch, but the file hash is different, the local file should be renamed, and then uploaded as a new file back to OneDrive.
  • In the case where the file exists locally , and the file was previously in sync , if the local file will be replaced by the online version, as the online version is the source of truth.

• When using --local-first (irrespective of --sync or --monitor or --resync) the files locally are the source of truth - thus the local file is the file to trust as correct (content, timestamp etc) and accurate and is the source for the online file copy.

  • In the case where the file does not exist online, the file is uploaded
  • In the case where the file exists (posix match) the online file is replaced. The older item can be retrieved online via file version history function online.

For all your extreme cases above, please replicate with the Microsoft OneDrive on a Windows platform without using files-on-demand and report back as to what the Windows client is doing.

Observations

Case 1-1 & Case 1-2

• 1.txt is an empty file and in-sync, thus, the online copy, because of the mode of operation being used (--sync) the online copy is what is being brought down. If --monitor was being used, the moment the local file was edited, this would have been uploaded.
• This is not a bug but an extreme edge case
• Replicate with the Microsoft OneDrive Windows Client and report back

Case 2-1 & Case 2-2

• 1.txt is an empty file and in-sync, and because --local-first is being used, the local file (the current empty file) is the source of truth.
• The local file is modified, then the online
• The local file is uploaded, as the local file is the source of truth
• This is not a bug but an extreme edge case
• Replicate with the Microsoft OneDrive Windows Client and report back

Please can you replicate your cases using the Microsoft OneDrive Client on Windows and report back

[JC-comp]

@abraunegg

1. I believe the cases I mentioned here are not rare extreme edge cases; they can easily occur when changes are made from both sides, even in monitor mode.
2. Currently, the strategy here always selects one side to replace the other side in case of conflict. If this behavior is intentional and not a bug, it highlights the necessity for a timestamp-based first mode, which preserves the latest version across all sites, as initially requested in the rejected #2617.
3. The Microsoft OneDrive Client on Windows operates only in singular mode. Microsoft's conflict resolution strategy dictates that the online version will always be preserved, while any conflicting local versions will be safely backed up with an appended host name postfix. So in all cases, the outcome results in two files: the online modification in "1.txt" and the local modification in "1-hostname.txt".

[abraunegg]

@JC-comp
As per above - please provide evidence replicating your issue using Microsoft Windows - not theorising what may or may not happen.

Screen shots and visualisations of what is occurring when using Microsoft Windows & Windows OneDrive client please - not text based theory.

[JC-comp]

@abraunegg
When both the local and remote files are modified simultaneously with the OneDrive app running, the final result remains consistent regardless of which side saves first. Microsoft ensures a local backup is created and preserves the online version.

[abraunegg]

@JC-comp
Use Case 1-1 and Case 1-2 - not a bug

Use Case 2-1 and Case 2-2 resolved with fecec1b

Additionally, please read:

• https://github.com/abraunegg/onedrive/blob/onedrive-v2.5.0-alpha-5/docs/client-architecture.md
• https://github.com/abraunegg/onedrive/blob/onedrive-v2.5.0-alpha-5/docs/client-architecture.md#file-conflict-handling---default-operational-modes
• https://github.com/abraunegg/onedrive/blob/onedrive-v2.5.0-alpha-5/docs/client-architecture.md#file-conflict-handling---local-first-operational-mode

[abraunegg]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.