Metadata for .mov files radically different to originals
My iPhone's photos and videos are backed up to OneDrive. The files are al synced to my PC hard drive. I'm just clearing off some of the larger .mov files from my iPhone as a quick way to make space. I reconcile that they've definitely been backed up by finding the file on my PC. Only, when I'm doing this the videos aren't there! Thankfully, they are, but with completely different dates and timestamps. For example, a video I took at 0715 on 1 December 2025 shows on my PC as 2 December 2025 at 1458! This is a nightmare scenario. I've also tried Date Created, Date Modified and Date Taken (always blank for .mov files) but none accurately correspond with the correct date and timestamps on my iPhone. Has anyone else experienced this or found a work around?
Corrupted VT+ transaction files
We are a small accounting company using VT+ Transaction on a local drive synchronized with OneDrive for backup and file storage. A few days ago when we tried to open the application, we suddenly started receiving the following error messages: Run Time Error 0 and Run Time Error 440, and the program does not start. According to VT+ support the program files are corrupted and the data can only be restored up to the year 2022, as the more recent backups are also affected. Somehow the system is overriding our backups, which makes the latest ones unusable. Any advice what could cause that and how to resolve the issue. ThanksSynchronization issue with unknown files
Hello. I have synchronization issue with 2 uknown files since 2 years or so. During that period I've restarted synchronization once. It didn't help. The weight of files sometimes changes what suggests that those files are in constant use. I would have excluded them from synchronization, but I can't identify them. There is no place where I could have found the name and location of those files. Does anyone know, by any chance, where are any logs or how to enable them, if they are not enabled by default, to troubleshoot that? Thanks in advance for any help in that matter... and Happy New Year!!
Face scan recognition limits?
I was a big fan of adding name tags in photos before, and was eager to have it back. Problem is, I have quite a large number of photos, and onedrive just stopped scanning, being very far from finishing the job. I mean, considering for example the pictures my spouse appears in, one drive started recognizing her in the most ancient photos quite nicely, but stopped somewhere in 2006, and than added just a dozen from the most recent pictures. Yes, I keep taking photos of her meanwhile. Unfortunately it didn't accept help from me, like hey look here, this is a face, and is the face of this person. Any idea if this is just temporary?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.
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
