Unable to use Robocopy in 1803 or newer

sml156 said:

I would try and temporarily disable Controlled Folder Access

Settings > Update and Security > Windows Security > Virus and Threat Protection > Virus and Threat Protection Settings > Manage Settings > Click off

Or the fast way

Press the Windows key > type " Controlled Folder Access " then click off

If this works you can allow robocopy there too, just click on " Allow an app through controlled folder access "

Note:
Turn Controlled Folder Access back on when your done

Edit:

You can use Powershell to enable and disable controlled folder access.

Open Powershell as admin and type or paste this command

Code:

Set-MpPreference -EnableControlledFolderAccess Disabled

To re-enable it use this command

Code:

Set-MpPreference -EnableControlledFolderAccess Enabled

Thank you for your suggestion. Unfortunately, the changes had no effect on allowing RoboCopy to accept the \Budget Data level folder. I'll keep experimenting but have no hope of a vendor fix since they have Not responded to FeedBack Hub inputs on this since my Insider inputs before 1803 release.

Try3 said:

Oh dear. The difference between xcopy & robocopy symptoms makes no sense to me either.
- I assume that the xcopy experiment was run in the same way as the robocopy ones: same computer, same source, same destination.
- I assume that you checked both sharing & security settings [your posts only mention sharing settings] - Properties, Security, Advanced.

By the way, the SyncToy forum still seems to be active so you might see if you can solve your original problem there.

Sorry I could not help,
Denis

Yes to your assumptions, thanks for the help. Also I had no idea SyncToy still had a forum, thanks for that also. Have a good day!

Try3 said:

I'm reading my old RoboCopy notes to see if there is anything relevant to your issue.
- Is there any chance that either the source** or the target computer is using the target folders / files during the procedure or shortly before it [without having yet released its folders/files]? That could explain the access errors.
** The error you report concerns the destination not the source but that might just be RoboCopy doing its best to interpret what is going wrong but getting confused in doing so.
- Running RoboCopy as Admin might yield additional symptoms that might assist diagnosis.
- Running RoboCopy on the target computer instead of the source computer might yield additional symptoms that might assist diagnosis {so it would be the source that contained a network address and the destination a local one}.
- I have previously witnessed odd RoboCopy behaviour when using network destinations but this was confined to attempts to copy Outlook .pst files rather than the general ones you are dealing with.

Don't forget that solving this problem will not allow you to use RoboCopy as a two-way sync tool. You cannot run it from A to B then run it from B to A with useful results; such an arrangement does not handle file deletions & renames properly. RoboCopy is only ever going to be useful for one-way 'syncing' which is what I use it for [One of my computers is the Controller. I RoboCopy to the Backup computers. I use separate procedures to 'sync' back individual files that get changed when I am working on one of the Backups.]

I suspect that if your requirement is for a two-way sync tool then you will end up having to adopt a third-party one. I know I have seen some recommended in TenForums but I have not made any notes about them. You could try skimming through threads about sync and threads about robocopy.

One aspect of this problem still intrigues me. Why do your destination folder paths include Program files (x86)?

Denis

All attempts to run Robocopy from Machine A to Machine B have been immediately after booting to !803-1809 on both machines.
Machine A is Always the Master file holder, no two way sync.
Program Files (x86)\ is where the DataBase Front-End (program) is installed. Other destinations contain the Back-End (actual Data Tables) .
Since I have Never had a problem with SyncToy (or RoboCopy) in all versions of Windows up to the 1800 series I can only lay the blame to whatever Microsoft screwed up in their desire for "improvement" and lack of company Beta Testers and deaf ears to Insider inputs.

Thanks for you help and suggestions but I believe this poor horse has expired.

I am late to this conversation but I use SyncToy with Windows 10 1809 17763.292 to sync files across my network as well as between drives on my primary system. What problem were you having?

pbcopter said:

I am late to this conversation but I use SyncToy with Windows 10 1809 17763.292 to sync files across my network as well as between drives on my primary system. What problem were you having?

Please see Post #4 for examples.

I looked at Post #4 and I see nothing about SyncToy which you mentioned in the original post. I will just bow out since I do not use Robocopy. Cheers