Forum Discussion
How does local OneDrive determine if a local file needs to be updated?
When using multiple computers to edit a OneDrive file, a computer often fails to recognize its local copy needs to be updated, even though the file on all computers is set to "Always keep on this device." This means changes are lost with no conflict error generated. Is the OneDrive algorithm for deciding when to update a local version of a file documented anywhere?
Usually when a change is made to a file, it starts uploading to the cloud within seconds. Within several seconds after the changed file is uploaded, other computers will recognize their local copy is outdated and will begin downloading the changed version. That is the expected behavior. But often, that doesn't happen. The outdated version is used to make new changes. Those new changes are uploaded successfully. No conflict warning is generated. The earlier changes are lost forever.
I have not found any documentation on how local Windows OneDrive decides if its local version of a file needs to be updated. Is it looking at file size? Timestamps? If timestamps, is there a margin of time sync differences? Does the OneDrive metadata include the source device of the last upload? Not knowing any of this I cannot troubleshoot the problem much beyond establishing that the problem is not with uploading changes. OneDrive local is reliably uploading changes. MD5 hash codes in the cloud match the hash of the changed file on the source computer.
I don't have time to jump through hoops with someone at frontline Microsoft support who doesn't know any more about the algorithm than I know in order to get the issue escalated to someone with the information needed to pinpoint the issuse.
1 Reply
Microsoft does not publicly document how the OneDrive client decides whether a local file needs to be updated. From observed behavior, the client relies mainly on cloud version IDs and cached metadata, not on continuous hash comparison. If a client fails to notice that a newer cloud version exists, it may treat an outdated local copy as current and upload it, silently overwriting newer changes. No conflict is generated.
Important points:
- “Always keep on this device” ≠ always up to date
- Timestamps and file size are only weak signals
- Hashes are not rechecked on every sync
- Sleep/wake, network changes, and long-open Excel files make this more likely
- This results in last-writer-wins data loss
This behavior is known but undocumented, and frontline Microsoft support cannot explain or change it.
Practical Workarounds / Mitigations
Before editing important files
- Pause and resume OneDrive sync
- Wait for “Up to date” status
For shared Excel files
- Use Excel co-authoring (open from SharePoint/OneDrive web)
- Avoid editing the same file on multiple machines offline
- Enforce “one editor at a time” for critical files
Reduce risk
- Enable and increase version history
- Avoid long-running open Excel sessions
- Avoid rapid edit-close-open cycles across devices
For critical workflows
- Treat OneDrive as distribution, not source of truth
- Use SharePoint, document management, or another system for authoritative storage
Bottom line
This is not user error. It’s a limitation of the OneDrive sync model.
If silent data loss is unacceptable, OneDrive sync alone is not sufficient.My answers are voluntary and without guarantee!
Hope this will help you.
Was the answer useful? Mark as best response and like it!
This will help all forum participants.
