Repository navigation
Local/Remote Path Conversion Bug #39
Description
Diagnostics
Win VBA7 x64
Accounts found: 1
Name: Business1
ID: cc315d33-cf49-41d0-8485-10969c2f6fe1
Has DAT: false
Is Valid: true
Providers found: 2
Base Mount: C:\Users\EG\OneDrive - Company
Is Business: true
Is Main: true
Mount Point: C:\Users\EG\OneDrive - Company
Sync ID: ffcb1524-1de5-4fd5-98ae-ff2929118adf
Web Path: https://company-my.sharepoint.com/personal/user_company_com/Documents/
Base Mount: C:\Users\EG\OneDrive - Company
Is Business: true
Is Main: false
Mount Point: C:\Users\EG\OneDrive - Company
Sync ID: ffcb1524-1de5-4fd5-98ae-ff2929118adf
Web Path: https://company.sharepoint.com/sites/Company/Documents/
Describe the bug
I am using this code:
Dim SourceFile As String
SourceFile = GetLocalPath("https://company.sharepoint.com/sites/Company/Documents/General/Subfolder 1\Subfolder 2\Subfolder 3\file.xlsm")
It should return:
C:\Users\Username\OneDrive - Company\Documents - Company\General\Subfolder 1\Subfolder 2\Subfolder 3\file.xlsm
but it returns:
C:\Users\Username\OneDrive - Company\General\Subfolder 1\Subfolder 2\Subfolder 3\file.xlsm
Additional context
Hello Christian,
i guess Microsoft updated OneDrive once again and changed the way the path conversion functions.
Thanks for the quick fix in advance!
Best Regards
Moritz
Activity
ERLoft commentedon Jul 13, 2026
Can confirm. Microslop changed it up again and it is now missing part of the directory path.
Fix for #39
cristianbuse commentedon Jul 14, 2026
Thank you for raising this. Please let me know if the last commit fixes the issue.
BlgTiFi commentedon Jul 14, 2026
Hello together,
I ran into the same problem. This did not fix the issue for me.
Please be aware when replicating it, that in some cases the bug disapears on its on.
So when I just tested the last commit i had to build a new test, because the issue did not persist with two tests i ran on friday.
A new user of an internal tool reported the issue last Friday and for him the issue persisted.
The day before that, he used the tool for the first time and showed to me, that it was working fine.
I was able to recreate the problem on Friday by:
The function then returned "C:\Users\name1\OneDrive - CorporateName"
Expected value was "C:\Users\name1\OneDrive - CorporateName\Teams Team 2 - Folder 1"
In the report of the Diagnostic Tool, the Mount Point had the same value this function returned.
Then something strange happened.
I proceeded testing with a diffrent copy and the issue dissapeared for the first one.
I created a new folder in a diffrent channel of the same Teams Team dropped a copy of the excel file there and used the "Add to OneDrive" on the whole channel this time, instead of the folder directly.
The second test case produced the same issue. But the Diognostic Tool now showed the expected value for the location of the first test case.
I then ran the first test case and it worked as intended.
Note that it also continues to work fine for everybody else (no other new users).
Best regards,
T.
Version:
DiagnosticsOD.txt after the second test:
Win VBA7 x64
Accounts found: 1
Name: Business1
ID: dadd8480-6a2b-4e32-83a7-195207553d42
Has DAT: Falsch
Is Valid: Wahr
Providers found: 3
Base Mount: C:\Users\name1\OneDrive - CompanyName
Is Business: Wahr
Is Main: Wahr
Mount Point: C:\Users\name1\OneDrive - CompanyName
Sync ID: 78ffa209-2a3f-441e-a75a-0199197b8d87
Web Path: https://companyname-my.sharepoint.com/personal/firstname_lastname_companyname_topleveldomain/Documents/
Base Mount: C:\Users\name1\OneDrive - CompanyName
Is Business: Wahr
Is Main: Falsch
Mount Point: C:\Users\name1\OneDrive - CompanyName\Teams Team 1
Sync ID: 78ffa209-2a3f-441e-a75a-0199197b8d87
Web Path: https://companyname.sharepoint.com/sites/Teams Team 1/Freigegebene Dokumente/Channel1/
Base Mount: C:\Users\name1\OneDrive - CompanyName
Is Business: Wahr
Is Main: Falsch
Mount Point: C:\Users\name1\OneDrive - CompanyName
Sync ID: 78ffa209-2a3f-441e-a75a-0199197b8d87
Web Path: https://companyname.sharepoint.com/sites/Teams Team 2/Freigegebene Dokumente/Channel1/Subfolder1/
Additional fix for second issue raised in #39
cristianbuse commentedon Jul 14, 2026
@BlgTiFi I can confirm the weird behaviour - the last added shortcut to OneDrive is not being syncronized properly inside OneDrive's SyncEngineDatabase.db file. However, as soon as you add a new shortcut, the previous one gets fixed. Just pushed a commit - can you please check? Thanks!
ERLoft commentedon Jul 14, 2026
I tested on one file set and it was successful. I've installed the updated module on the computers for the rest of my team. They mostly use OneDrive. I personally hate OneDrive, so I use Dropbox and then use FreeFileSync to back up my business Dropbox files to the company OneDrive account nightly. As such, I don't really have issue. But I'll report back if any of the rest of my team do run into issues. Thanks much!
BlgTiFi commentedon Jul 14, 2026
@cristianbuse
This fixed the issue for me as well as for my colleague!
Thank you very much for your work and quick response.
sawessels commentedon Jul 14, 2026
Hello Christian,
While attempting to run LibFileTools.CreateODDiagnosticsFile on a client machine, I encountered run-time error 9 (Subscript out of range) in LibFileTools.ReadDirsFromDB.
Execution broke on line:
nameSize = b(j)
At the time of the break, the value for j=0.
The user machine is:
64-bit Windows 11 Enterprise
Version 24H2
OS build 26100.8655
Seems to be a machine specific issue, attempting the same operation on my machine, successfully completed. Both machines are operating in the same enterprise environment.
Fix for 3rd issue raised in #39
cristianbuse commentedon Jul 14, 2026
Thanks @sawessels , please let me know if the current commit solves the issue.
sawessels commentedon Jul 14, 2026
Hi @cristianbuse ,
The latest release took care of this last issue as well as the original handle with managing the change from Microsoft, its working well in all regards.
Thanks for the speedy work on this fix.
4lm1ghty commentedon Jul 15, 2026
Hey, sorry i am late to the party.
This fix works for me.
Thanks for the fast response as always.