Služba Microsoftu pro hostování a synchronizaci souborů.
Hi Xavier-D,
Following up on our thread from June, since I now have additional information that seems important.
You told me on June 26 that since both my Windows devices were fully powered off at the time, it was reasonable to suspect the June 7 deletions originated elsewhere - "another signed-in device, web/mobile access, shared folder activity, or a cloud-side/account-level change."
Around the same time, in a separate Microsoft Support case ([Moderator Note: Personal Info Removed], running in parallel), the support agent told me the opposite: that "the OneDrive service itself does not independently generate file changes without a prior trigger," and that the deletions were most likely local changes from a previous sync session that only became visible later.
Since then, a similar mass-deletion incident happened again on July 6, and this time I was able to analyze the local OneDrive Sync Engine diagnostic logs directly (decrypted using the client's own general.keystore). Immediately before 104 files were deleted, the logs show:
WnsClient::OnNotificationReceived (an incoming push notification) -> SyncServiceProxy::StartChangeEnumeration (a request to the server for changes) -> a server response (EnumChanges) -> every one of the 104 deletions tagged with the same internal trigger: DeletionTrigger::FindChangesTombstone
This looks consistent with your original explanation (something server/account-side), not with the "local session, delayed visibility" explanation I got from Support.
Could you help me understand which of these two explanations is more accurate? And is there a way to have this looked at by someone with access to server-side sync telemetry, given that the local logs point fairly specifically at a server-originated tombstone rather than a local-only event?
Thank you again for your time.