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.
Move files from Account A to Account B 165 GB data
I’ve been using Microsoft Office 365 Family for several years, sharing it with my family members. We have 6 accounts, each with 1 TB of storage. One of my accounts has now reached 985 GB, so I need to transfer files from Account A (my account) to Account B (my wife’s account). These files mainly consist of photos and videos — over 200,000 files in total. I tried transferring a 6 GB wedding shoot (.ISO format), but it took more than an hour. Re-downloading and uploading all the data isn’t feasible as my internet connectivity is limited to 100 mbps only. I’m looking for the best and most efficient way to move these files directly between OneDrive accounts.
Some Fabric Lakehouse tables not appearing in Microsoft Purview after scan
Hi everyone, I’m running into an issue where several tables from a Fabric Lakehouse aren’t appearing in Microsoft Purview after a workspace scan. Here’s the situation: I scanned a Fabric workspace that contains multiple Lakehouses. For most Lakehouses, the tables appear correctly in Purview after the scan. However, for one specific Lakehouse, several tables that I know exist aren’t showing up in the scanned assets — even after adding the Lakehouse as an asset to a data product in the Unified Catalog. What I’ve tried: I rescanned the workspace and the specific Lakehouses. I verified that the tables are persistent (not temporary) and appear under the Tables section in Fabric, not only as files. I confirmed permissions for the Purview connection account. Scan results and errors: After the rescan, the tables still didn’t appear. The scan logs show several ingestion errors with messages like: Failed to ingest asset with type fabric_lakehouse and qualified name [qualified name] due to invalid data payload to data map I checked the error entries to see which assets they point to, and none of them are related to the tables in the Lakehouse in question. There were four of these errors in the last run. Additional context: Some older Lakehouses that had been archived months ago in Fabric still appeared as active in Purview before the rescan, so there may be stale metadata being retained. Notes: I’m aware Fabric scanning in Purview currently has sub-item scanning limitations where item-level metadata is prioritised, and individual tables aren’t always picked up. But given that tables from other Lakehouses appear as expected, and given the ingestion errors (even though the errors do not point to the missing tables), it feels like there may be a metadata sync or processing issue rather than a simple coverage limitation. Question: Has anyone encountered this behaviour or the “invalid data payload to data map” error before? Any guidance on further troubleshooting steps would be appreciated. Thanks in advance!
Ghost Profiles Persist in Edge Profile Switcher Despite Cleanup
I've submitted a detailed Feedback Hub report documenting persistent ghost profiles in Edge’s profile switcher. These profiles remain visible despite full local and registry cleanup, and there’s no user-facing way to remove them. The issue affects profile integrity, sync behaviour, and UI clarity. It’s reproducible and has no current resolution. Here’s the link to my Feedback Hub submission: https://aka.ms/AAykvpv If you’ve experienced this issue, please upvote or share your observations. Let’s help Microsoft prioritise this fix.Ghost Profiles Persist in Edge Profile Switcher Despite Cleanup
I've submitted a detailed Feedback Hub report documenting persistent ghost profiles in Edge’s profile switcher. These profiles remain visible despite full local and registry cleanup, and there’s no user-facing way to remove them. The issue affects profile integrity, sync behaviour, and UI clarity. It’s reproducible and has no current resolution. Here’s the link to my Feedback Hub submission:https://aka.ms/AAykvpv If you’ve experienced this issue, please upvote or share your observations. Let’s help Microsoft prioritise this fix.
OneDrive changes metadata on files
I'll try to make this brief. OneDrive is not accepting/changing the metadata on my images after edit. What happens is this: 1) I create an image file with keywords in DAM 2) OD uploads correctly. 3) I make a change to the file, e.g. keywords 4) OD uploads OK. Then 5) a minute or two later OD redownloads the file without the keyword edit, reverting to previous version. 6) DAM sees the change, and reverts the keywords. And then I'm in a perpetual loop. I have had 2 MS support cases on this, supplied videos, had screen share sessions and on all occasions, the support agents stop responding either by email or by phone. This is a very worrying issue and I see that others have experienced this over the last few years. I have had to remove my Photo library from OD, work on a local drive and rely on backups. Does anyone have any idea how to resolve this?
How can I force OneDrive to accept metadata for images and photos 1:1?
Is there any way to force OneDrive to save images as an exact copy of the original local files, including all changes to metadata? In detail: I have massive problems with using OneDrive as a data storage for photos, as OneDrive is often unwilling to accept changes to metadata (especially tags or geo-coordinates). The problem seems to have existed for years, as you can read in various places: https://www.dpreview.com/forums/thread/4527626 - OneDrive reverts changes to IPTC (!) https://answers.microsoft.com/en-us/msoffice/forum/all/onedrive-randomly-re-creates-pictures-some/7ca06735-eac2-470d-8c54-77adc7955d5c https://www.lightroomqueen.com/community/threads/lightroom-with-onedrive-keyword-metadata-conflicts.41753/ and other places. I also have the problem that I change the metadata of my images with digiKam, but that these changes are then often not accepted by OneDrive. There is then a file conflict, OneDrive renames my local files and I then have two variants. Or the changes simply do not arrive in OneDrive and are not even recognized as changes. In other words, it is not possible to reliably change image metadata when the folder is synchronized with OneDrive. So I tried the following workaround to at least have a secure and exact copy of my data somewhere: - I now use local folders for pictures and videos that are not synchronized with OneDrive - I synchronize these local folders via "Synology Drive" one-way (from the PC to the Synology) with a Synology Diskstation - "Chloud Sync" runs on the Synology to synchronize the changes from the Synology to OneDrive one-way. - The aim is for the data in OneDrive to also correspond to the local data on my PC The synchronization from the PC to the Synology works. I can compare data with WinMerge and the data on the Synology corresponds to the local data. The synchronization from the Synology to OneDrive does not work properly: I can synchronize the data from OneDrive to my PC for testing and comparison. If I now compare my original local images with those that come back to my PC via the detour "local -> Synology -> OneDrive -> local 2", many changes in the metadata of the images are not adopted.
OneDrive: High SSD I/O Since Mar 2025 Update, mklink /j Junctions Suspected
Bug Report: Suspected NTFS Junction (mklink /j) Interaction Causing Excessive OneDrive SSD Read/Write Activity on My System Since March 2025, Potentially Linked to Recent OneDrive Update Date: June 2, 2025 Product: Microsoft OneDrive Operating System: Edition: Windows 10 Pro for Workstations Version: 22H2 OS Build: 19045.5917 Installed on: 2024/9/24 Experience Pack: Windows Feature Experience Pack 1000.19061.1000.0 Summary: Since approximately March 3rd/4th, 2025, OneDrive has been causing an extremely high and sustained level of read/write activity on my system's SSD. Notably, I have been utilizing the same configuration, including Git repositories within OneDrive and NTFS junction points (mklink /j), since October 2024 without any such issues. This abrupt change in behavior starting March 2025 strongly suggests that a recent OneDrive update may have introduced a regression or altered its handling of these elements on my system, leading to the current problem. This behavior is significantly impacting my SSD's health and potentially my system's performance. Date First Observed: The issue began noticeably on my system around March 3rd, 2025, with a sharp increase in disk write commands observed from March 4th, 2025, onwards, as evidenced by the "Host Write Commands" graph (see attached picture 1). Problem Description: On my system, OneDrive.exe consistently exhibits high I/O read and write byte counts, leading to excessive disk activity. This is evident from: The long-term graph of "Host Write Commands" (picture 1), which shows a dramatic and sustained increase starting in early March 2025, rising from approximately 3,500,000,000 to over 12,000,000,000 by late May 2025 on my system. Process monitoring tools (picture 3) show OneDrive.exe with significantly higher "I/O Read Bytes" and "I/O Write Bytes" compared to other active processes on my system. For example, OneDrive.exe shows I/O Read Bytes in the hundreds of millions and I/O Write Bytes in the hundreds of millions, far exceeding other applications. Resource Monitor details (picture 2) confirm OneDrive.exe as the process with high disk activity on my system, specifically reading and writing to its operational database files such as SyncEngineDatabase.db-wal and SyncEngineDatabase.db. The screenshot shows these files located at H:\OneDriveINTEL\OneDrive\Settings\Business1\, which is where I have relocated my OneDrive cache or settings using mklink /j. (It is important to note that this relocation is not believed to be related to the cause of the excessive I/O from OneDrive; rather, I performed this relocation because my primary C: drive was already subject to frequent writes and its lifespan was a concern. The excessive I/O from OneDrive simply followed the cache to its new location on drive H:.) Potential Contributing Factors to Observed Behavior on My System: Use of NTFS Junction Points (mklink /j): I utilize mklink /j in conjunction with OneDrive. This involves junction points within my OneDrive folder pointing to other locations, and I also used it as a troubleshooting step (relocating OneDrive's cache, as mentioned above). This is a primary suspected trigger for the excessive I/O. (See "Additional Context Regarding mklink /j Usage" below for specifics). Use of Git Repositories: I store and manage Git repositories within OneDrive-synced folders. The frequent small file changes typical of Git operations might be triggering excessive sync activity, possibly exacerbated by the interaction with junctions. Troubleshooting Steps I Have Already Taken: I identified OneDrive as the primary source of high disk I/O using system monitoring tools. I relocated my OneDrive local cache/settings folder (typically C:\Users\[Username]\AppData\Local\Microsoft\OneDrive) to a different physical drive (Drive H:, path appears to be H:\OneDriveINTEL\) using mklink /j, as detailed in the Problem Description. Despite this relocation, the excessive I/O pattern persists on the drive now hosting these OneDrive operational files. I attempted to reset OneDrive settings and functionality. I performed a full reinstallation of the OneDrive application. Neither resetting nor reinstalling OneDrive resolved the excessive disk I/O issue on my system. I can confirm I have used Git repositories within OneDrive folders and mklink /j for other purposes within my OneDrive setup since October 2024; the problem only manifested in March 2025. Additional Context Regarding mklink /j Usage: It is important to clarify that my use of NTFS junctions (mklink /j) differs from some scenarios discussed in public forums (e.g., the Microsoft Answers thread at https://answers.microsoft.com/en-us/msoffice/forum/all/solved-onedrive-constantly-writing-to-disk-to-the/68958911-1161-4c5e-b920-dee7e55bc0ac). In my case, the junctions are created between locations that reside on the same hard drive. For instance, a typical mklink /j command I use creates a junction within one of my OneDrive-synced folder structures that points to another directory also located on the C: drive. An anonymized example reflecting my usage pattern is: mklink /J "C:\Path\To\My_OneDrive_Business_Account\MainSyncFolder\ProjectX_Vault\Subfolder_A\Notes_Junction" "C:\Another\Local_Path_SameDrive\ProjectX_SourceData\RawNotes_Target" This type of same-drive junction configuration, where the junction link is inside a OneDrive folder and the target is elsewhere on the same drive, was part of my stable setup from October 2024 until the onset of the excessive disk I/O issue in March 2025. Expected Result: OneDrive should synchronize files and perform background operations with reasonable disk I/O that does not lead to constant, excessive read/write activity, especially when my system is idle or with minor changes. Disk activity should not be at a level that significantly impacts SSD lifespan or system responsiveness, even when NTFS junctions (including same-drive junctions as described) are part of the configuration. Actual Result: OneDrive is causing continuous and abnormally high SSD read/write operations on my system, as detailed by the attached screenshots. This has been ongoing since early March 2025, and I strongly suspect it to be related to its handling of NTFS junctions as configured on my system. Impact on My System: Potential reduction in SSD lifespan due to excessive writes (this was already a concern for my C: drive, prompting the cache relocation, and is now a concern for drive H: due to OneDrive's behavior). Possible degradation of overall system performance and responsiveness. Concern over data integrity and system stability. Attachments: picture 1: Graph from my system showing "Host Write Commands (FF_1250)" over time, illustrating the sharp increase in writes since March 2025. picture 3: Screenshot from a process monitoring tool on my system (similar to Process Explorer) showing high I/O activity for OneDrive.exe. picture 2: Screenshot from Resource Monitor on my system (or similar, in Chinese) showing disk activity by process, with OneDrive.exe prominently active and detailing file access to its database files on drive H:. Request: I request an investigation into why OneDrive, particularly after a potential update or change around March 2025, began exhibiting this excessive disk I/O behavior on my system. I ask for a strong focus on its interaction with NTFS junctions (mklink /j), especially same-drive junctions as detailed in my "Additional Context" section, and particularly in environments also using Git. This configuration worked without issue for me from October 2024 to early March 2025. Guidance on how to mitigate this issue or information on a forthcoming fix would be greatly appreciated. Picture 1 Picture 2 Picture 3
