OneDrive For Business - folder named forms not at root

[QSS-Support]

Hi,

I'm getting errors like these when synching to OneDrive For Business :-

Error creating folder. It's possible that the server does not allow this name:
ext://OneDrive for Business/Folder1/Old Documents/Forms
Error creating folder. It's possible that the server does not allow this name:
ext://OneDrive for Business/Folder1/Old Documents/Forms/Company Files
Error creating folder. It's possible that the server does not allow this name:
ext://OneDrive for Business/Folder2/Old Documents/Forms/Clients

and so on. In other words, any folder with Forms as a subfolder name fails.

I'm aware that OneDrive for Business does not allow the folder name Forms but only if it was at the root level of a list or library (source : https://support.microsoft.com/en-au/kb/2933738).

I can manually create the folder called Forms at the subfolder level where Syncovery reports that it can't, so I don't think it's a OneDrive limitation. Is this being blocked by Syncovery itself ?

Thanks.

CK

[superflexible]

Syncovery does not cause this error. It must be a bug, or an additional limitation, of the OneDrive API when used with OneDrive for Business.

[QSS-Support]

OK. Thanks for the info.

There must be quite a fair bit of limitations with the API.

I've been trying to sync one of my server shares to OneDrive for Business and after a week of trying it still has not finished. I get all kinds of errors and messages (in addition to file name limitations, etc) I very frequently get Cloud related delays (or something to that effect) which might be throttling (?) at MS end ?

I read other blog posts that other have been using a variety of software to sync their shares to ODFB and most are simply using things like FreeFileSync and one even used MS SyncToy ! The major difference was they mapped their ODFB to a drive letter locally then sync'd to that drive letter. So, I cancelled my Syncovery sync which was running for a week, created a new target on ODFB then mapped it to a drive letter. I then created a new Syncovery job to Sync to that drive letter and did not allow Syncovery to convert the mapped drive to its UNC name then ran the job.

What a difference ! Not only did it generate a lot less errors, it also managed to finish the whole sync in 2 days (while the previous job using the API still has not finished after a week) !.

One would have thought the whole purpose of the API was to provide a better experience in accomplishing the file copy.

Regards,

CK

[superflexible]

Hello,
many thanks for sharing this info! Yes I wished the API would work better too. I hope one day it will.

[QSS-Support]

Ok. It seems if I sync using a mapped drive letter to ODFB, the only scheduler that works is the foreground scheduler. Neither Background not Service scheduler can access the mapped drive and I have already set the Syncovery service to run as the same user account that the server is currently logged in as (who has access to the ODFB mapped drive).

Any other way to get this to work with either Background or preferably the Service scheduler ?