OneDrive and directory junctions sync problems
With Dropbox’s end of Linux support I have been on the search for alternatives, as I will quit my Dropbox contract and need to move considerable data to a different provider. Since I am also a Office365 subscriber I get 1Tb of free OneDrive space, which should be usable. With recent updates of the onedrive package in Debian I am maintaining, using it instead of Dropbox has become a feasible alternative. I also started to use OneDrive extensively on the Windows side to sync my Desktop, documents, and my GPS and Map data (history of 20 years of GPS tracks and loads of maps). Advertised all over the internet (eg here, here, here) is a method to use directory junctions to link arbitrary folders by creating a junction in the OneDrive folder that links to the original folder.
As it turns out, this does not work as expected: Assume the following setup
- There is a folder
c:\MyFolder
- A junction in
%UserProfile%\OneDrive\MyFolder
pointing toc:\MyFolder
and create a file c:\MyFolder\test.txt
. This file is kept in a pending synchronization state and is not properly uploaded to the server.
One can trigger the upload by various methods:
- pause and restart syncing
- change/create any file in
%UserProfile%\OneDrive\
If a sync is triggered by one of the above, also the pending changes in c:\MyFolder
are uploaded, but NOT otherwise.
This did hit me several times because I preferred to have the main folders not in the OneDrive directory, but in their original location. Experimentation turned out that if you do the link source and target switch, so that the actual folder is in the OneDrive directory, and the directory junction wherever you need it, files are correctly synchronized.
For those having the wrong setup already, the following steps allow to switch the direction without triggering a full resync:
- Wait until OneDrive has synced completely, then exit the program from the notification area;
- remove the junction with rmdir, this will not remove the original directory;
- move the original directory into the OneDrive folder;
- recreate the junction with
mklink /j c:\MyFolder %UserProfile%\OneDrive\MyFolder
; - restart OneDrive.
This should bring you back to fully synchronized state in a very short time, and further changes in either the OneDrive folder or the directory junction will immediately trigger a file sync operation.
Thank you so much! This fixed my OneDrive junction sync issue!
You are welcome, good to hear that it is not only me 😉
You’re the best!
You solved even my sync issues.
Note: This won’t work for user folders such as Downloads since Windows won’t allow you to point it to a symbolic link or junction.
Thanks for the additional information!
Awesome fix, thank you.
I’m confused. What do you mean by “move the original directory into the OneDrive folder”? If the original folder is D:\original, and I ‘move’ it to under the OneDrive folder, it’s no longer in D:\. How will the mklink command work when there is no D:\original to link to?
You move the `original` directory into the OneDrive folder, and then create a link from the OneDrive `original` to `d:\original` – but I think that will not work, because the OneDrive folder is probably on C:\ and I don’t think that junctions work across discs.
I want to store a lot of my data files on my D drive instead of on my C drive. I want to sync my D drive folders to OneDrive but your method looks like it also puts them on my C drive. Is this true? If so, is there another way I can sync my D drive folders to OneDrive without also having them on my C Drive?
Yes, the data would be on the drive that contains the OneDrive folder, which most probably is the c:\ drive. I am not sure how to deal with separate discs, sorry.
You can first create a symbolic link in the D disk, pointing to the desired folder in OneDrive. Then make a directory junction on the D disk from the symbolic link. That should work, I did that with my WSL install (which was on a network drive even)
I have my OS as WServer 2019 on C:\, I have saved my OneDrive business store on a separate hard drive in E:\ and am syncing files from a separate file store on H:\. I’m currently using this but I do occasionally have the sync issue this article mentions. Also, on WS 2019 I do not have mklink available. Although these are fixed paths, and I could use junction, I decided to create a Symbolic Link instead. It is the most flexible of the options for my scenario.
I had to use the following PowerShell command to get this to work:
=========
New-Item -Path “E:\OneDrive-LOCATION\[New OneDrive Folder]” -ItemType SymbolicLink -Value “H:\[File Store Location]”
=======
By creating the symbolic link to the target data store, inside of OneDrive, it does NOT duplicate the files and directly references the files on the H:\ drive. My OS (Win Serv 2019) is on an SSD that I do not want to risk putting a bunch of files on. At the same time, both the E:\ and H:\ drives are on very fast 2.5 spinning platters (10K rpm).
This is more than fast enough for anything I want to do. My only challenge is to resolve the sync issue this article lays out. Technically I’m okay right now. If I create a directory OR files, directly in the H:\ file store they are synced right away to OneDrive. If I create folders, files, or datasets in One Drive they are immediately synced to H:\ and E:\ does not grow from anything in there. HOWEVER, if I use a networked computer and do any file or folder updates in the H:\ store, through the network, they have the problem mentioned above. For me that is a minor annoyance for the moment. If anyone makes updates in the OneDrive folder (in Explorer or Online) everything is updated so we may just stop using that network store and require the OneDrive folder for direct updates.
Thoughts?
Not really. It seems that the missed updates are caused by the files not actually residing in the onedrive folder, and with your layout that is not doable. So the best is that you kick of sync at regular intervals.
Thanks Norbert for the reply. And for the article. After some experimentation I did discover that all sources of network drive updates do in fact eventually sync. We did *not* add any sync rules or trigger the sync beyond adding files to the server. Some time later the files and directories are synchronized. The only thing I can figure is Microsoft has some type of scheduled sync job.
Works perfec.
Thanks.
Thanks