Maybe that happens because OneDrive is actively syncing the file while DCP-o-matic is writing/recreating it.

But looks like a OneDrive issue to me.

• Carsten

Maybe we find other OneDrive users to confirm this issue. I understand there are different OneDrive configurations and addons. Maybe this happens only in specific scenarios?

• Carsten

Happens all the time for me. The contents of the OneDrive folder have special NTFS types that we aren't dealing with.

I think it's this bug: https://svn.boost.org/trac10/ticket/5649

So, is there something we can do about it? Should DCP-o-matic deal with bugs in other apps/libs?

Does it really only happen with 'Make DCP'? In that case, we could add a hint if we detect the file path to contain 'onedrive' - or is that too simple a thought? We could also give that hint right away when the project is created in a onedrive path.

• Carsten

I think we have to do something. You can't even open an old project if it's on OneDrive. Maybe patch boost for the Windows version, or maybe work around it in DoM.

Of course I have no idea in how far boost is needed for file access other than standard file operations.

The trouble is that OneDrive is not just an exotic tool. It's MS, and some people may use it now to store all their files in it, not just a dedicated folder. Probably more and more in the future.

While personally I am too conservative to store large files like DCPs in my dropbox per default, I could understand that people with large cloud storage and fast internet connections would love the idea to create their DCPs at home and then find them at the cinema automatically. As far as I know, with an Office365 account, you are allowed to use 1TB of cloud storage...

So, yes, maybe, sooner or later, there needs to be a solution.

• Carsten

oops. That Bug is 5-7 years old...does it really still exist? I learned that WIN10 introduced new NTFS attributes, explicitly for cloud storage (online, local, etc.). Maybe it's a WIN10 issue. I could test in WIN7. Which doesn't solve the problem. Maybe for the time being, catch the 'onedrive' string in paths and issue a warning immediately, even before doing something...Not elegant, but the error message they are getting now doesn't help either, so it's better to give them something they understand and can act upon. As we see on the mailinglist, it is not immediately evident to the average user that their OneDrive is the issue.

• Carsten

boost 1.67.0 does not appear to fix it. Everything in a onedrive comes back with status().type == 9 (both files and directories).

https://github.com/arduino/arduino-builder/issues/254

https://go-review.googlesource.com/c/go/+/86556/5/src/os/types_windows.go#121

This looks really unpleasant. For some reason it only seems to have become a problem with fairly recent Windows 10 updates. The go compiler has a fix (which makes the Arduino software work) and I think a similar concept needs to be applied to boost.

I thinks that's what I was referring to - the WIN10 Creators Update introduced these new NTFS File attributes...

• Carsten

So - issue a warning with anything 'onedrive' in it, or...? If it comes up more often, also for other apps, maybe it will be fixed in boost at some time. Do you want to be the one who fixes it? I have no idea how complex it could be...

• Carsten

https://devblogs.microsoft.com/oldnewthing/20100212-00/?p=14963

I'm back here today because someone had an error with some cloud file sync thing called "Box" (0002849) but I don't want to test it because you have to sign up with a credit card.

So I thought I'd try OneDrive again and it seems to work OK with a quick test on 2.17.19 / Windows 10.

Looks like Boost 1.81.0 (for DoM 2.17.x) has some code to deal with this REPARSE_POINT stuff (see is_reparse_point_tag_a_symlink).

But then this doesn't look so different to the stuff in 1.78.0 (for DoM 2.16.x).