"Folder path missing" even the path exists (OneDrive Win10 Fall Creators Update)

Thanks a lot for debugging this. I hope devs can develop a workaround since deleting the folder is not very handy after every boot.

To be clear, you are NOT deleting the folder.

You are deleting the reparse point associated with the folder. It’s basically metadata that OneDrive is using somehow. It seems that this has to deal with lower-level NTFS features that are way beyond my understanding as of now… But you can read more on reparse points here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365503(v=vs.85).aspx

Thanks, Geeksquad. I created a bug report to GitHub.

1 Like

So I don’t think we should fix this. The problem comes from the fact OneDrive uses something funky, not us.

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.

Would it be possible to explain how syncthing reads a directory? (I’m sorry if I’m boring you, I don’t really know golang.)

I wanted to see if it’s indeed a golang issue, so I wrote this quick script to just list out the files & directories of the OneDrive folder. (A quick test to read the OneDrive Folder in the current user's home directory. (Based off of: http://www.golangprograms.com/how-to-read-names-of-all-files-and-folders-in-current-directory.html) · GitHub)

From my testing, this script is able to get a listing of files and directories within the folder, with and without the reparse point metadata in place.


If we decide to not fix it, I’d suggest at least updating the error message with something more descriptive, since the folder isn’t actually missing. :wink:

Can you try this: https://gist.github.com/imsodin/6fe6d8c877a6a96b3da66f93aefaaf03

We could extend the message to say “folder path missing or inaccessible”, but that is still very general.

So I am actually upgrading my windows to this Fall Creator Break All Your Stuff update. Will see what that returns once it’s done.

1 Like

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.

So stat/lstat on OneDrive returns fine, it does however show up as a symlink, which essentially do not exist for us in Windows.

So probably Symlinks as folder root broken on Windows · Issue #4353 · syncthing/syncthing · GitHub is the first issue to solve (fs regression on folder roots that are symlinks in windows, afaics).

Not saying you should, but if someone wants to tackle it. :slight_smile:

Well, but I can’t repro this issue:

The issue doesn’t say of course, but I have a feeling the failure is the symlink traversal check

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?

Symlinks is a can of worms on Windows, and syncthing does not support them.

It seems the devs have fixed the issue! I am looking forward for the next release. Thanks devs and geeksquads for you persistence.

1 Like

Works great in v0.14.41! Thanks Devs!

2 Likes

The fix for this is not supposed to be in 0.14.41 though…

1 Like

The fix for this is not supposed to be in 0.14.41 though…

Well, something has changed since it works :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.