I am getting “Folder path missing” error message for an existing folder. The folder has the “.stfolder” -folder. The whole folder is locally synced OneDrive For Business folder that is being backed up to NAS using Syncthing.
I think the problem relates to the the Win 10 Fall Creators Update that introduced a new Onedrive “Files on demand”-feature that is turned on by default (as if I wanted to keep my files on cloud by default). I have switched this feature from Onedrive settings off, but it did not solve the issue with Syncthing. Any idea what to do?
I have both Onedrive and Onedrive For Business folders synced with Syncthing. I had the problem with both the folders, but the disabling the “Files On Demand” fixed the Onedrive folder sync, but it did not help with the Onedrive for Business sync. There are some error messages related to “readonly” folder too.
I have a similar(if not the same) issue as all these folks.
After some digging, I found that this is because OneDrive(After the new Creator’s Update) now makes the OneDrive folder a reparsepoint. To get around this, you’ll need to delete the reparsepoint on the OneDrive directory in order for Syncthing to recognize this directory again.
Specifically, you can follow these steps:
Stop OneDrive Sync. (Not sure if this is required, but I Exited the OneDrive Application in your toolbar icons section as well.)
Open the Command Prompt by clicking the start button and typing in “cmd” in your search bar.
In the command prompt, type in fsutil reparsepoint delete C:\Users\<your username>\OneDrive
The command should not return any message.
Restart Syncthing and see if it’s able to scan the directory again.
(In my situation, I also disabled the new “Files on Demand” feature.)
The only downside is that you’ll need to redo this process every time you reboot or start OneDrive. OneDrive seems to recreate this reparsepoint when it starts. I haven’t tried removing the reparsepoint while OneDrive is also syncing… since I’m scared I might corrupt something.
I think the fix should come from the Go standard library / runtime, much like the similar issue of NTFS deduplication. Both stem from the fact of the thing on disk being visibly something other than a normal file or directory, and we only sync files and directories - not reparse points or quantum teleportation tunnels or magic placeholders or whatever. If it’s supposed to act like a normal file or directory, it’s up to the OS or standard library to present it as such.
It might certainly be a bug in Go, though.
Edit: I see the NTFS dedup issue is closed Go-side now, so maybe that works for us. Or maybe it just exposes the deduplicated files as symlinks in which case we will legitimately still ignore them.
There’s also the thing that I’m sure it’s possible to read the directory and the files in it if you don’t look too closely at what you’re reading - just hold your nose, open the file, read the contents. But we take great care to not follow symlinks, not read or wipe out things like named sockets and pipes, and so on.
Hence, when the OS throws us something that is sort of like a file, sort of like a symlink, maybe neither and acts weird when you try to figure out what it is - we will take the safe route and skip it. Unison and other programs may have a different philosophy and take a different approach. That’s fine.
This is also a scariness around even trying to support syncing the OneDrive files. I assume that if you actually check that box, files will no longer be on disk unless they are in use, and then get automatically offloaded into the cloud. Syncthing will replicate that as a delete to everywhere. If that everywhere is another OneDrive folder, that will look like a regular user-initated delete to OneDrive. Poof, gone for real.
All in all, while it would be nice to support whatever funkiness Windows is throwing at us here, I think it’s probably a Bad Idea™ to sync your OneDrive folder using Syncthing.
Using the gist from Audrius Butkevicius, I’m able to read the directory with no issues (with the reparse point metadata in place):
My results of the script are at the bottom of the gist.
In the results, the OneDrive folder reports as a symlink, but directories inside the OneDrive folder are not. I’m still a bit confused as to why exactly it is reported as a symlink. If it’s a symlink, then shouldn’t you be able to see where the link is pointing to? Is the golang libraries mis-reporting the status of the folder?