none
Robocopy issue to SharePoint online

    Question

  • Hi all,

    I have mapped Drive Y: and Drive W, where Y is to a sharepoint 2010 Site and Drive W is to sharepoint online site.

    When I use drag and drop using File explorer it works, so all permissions are in place for both drives.

    I then used this command to copy file from Drive Y to Drive W:

    Robocopy "Y:\Shared Documents\Kunden" "W:\Shared Documents\Kunden" /E /V /ETA /log:file.txt

    It manage to create all folders in top hierarchy, but failed to create sub folders and copy any files. 

    Anything I'm missing?

    thanks!


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you. Thank you! Off2work

    Sunday, January 22, 2017 7:24 PM

Answers

  • Well, I did a test on a Windows server 2012  R2  that was not patched since 13.09.2016 and same command works.

    The other pcs (windows 10 Build 14393.693) did not work.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you. Thank you! Off2work

    • Marked as answer by Off2work Monday, January 23, 2017 8:56 AM
    Monday, January 23, 2017 8:56 AM

All replies

  • Hi Off2work,

    If need to copy the directory with all sub folder and files, we can use the command below to achieve it:

    Robocopy /S D:\dir1\data E:\backup\data

    More information:

    Robocopy command syntax and examples

    Robocopy command

    Thanks

    Best Regards


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, January 23, 2017 6:15 AM
  • Hi Jerry,

    thanks for your response. Your command didn't work at all, no folders was even created. Since /S switch doesn't copy/create empty folders (Even my folders and some subfolders are not empty)

    I tested my command again, but this time using local folders on C: drive and it worked.

    Robocopy "C:\Shared Documents\Test" "C:\Temp\Test" /E /V /ETA /log:file.txt

    Seems like some restriction over network drive. I tested with other network drives that are not from SharePoint, and they also fails.

    I ran CMD as admin, then mapped the drives in CMD, but still command didn't work. Anyone having same issue?


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you. Thank you! Off2work


    • Edited by Off2work Monday, January 23, 2017 7:49 AM Edit
    Monday, January 23, 2017 7:48 AM
  • Well, I did a test on a Windows server 2012  R2  that was not patched since 13.09.2016 and same command works.

    The other pcs (windows 10 Build 14393.693) did not work.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you. Thank you! Off2work

    • Marked as answer by Off2work Monday, January 23, 2017 8:56 AM
    Monday, January 23, 2017 8:56 AM
  • In my opinion, the above "answers" are not answers, although they are good related information to have.

    I have some scripts that use robocopy to do exactly this.  They run every night and started failing immediately after applying three Windows 7 patches in February (KB3210131, KB3205394, KB3125574).  I can repeat this problem at will, simply by running:

    ROBOCOPY UNCPathToSourceSHAREPOINTSERVER\SITE\FOLDER C:\DESTINATIONFOLDER /E /S /L

    It only lists the top level files/folders and shows FAILED for the top level folders where it did not traverse into the subfolders.

    I am using XCOPY as a workaround, but it does not have all the features of robocopy, particularly /MIR to prune out deleted files from the destination.

    Known Issue 4 of KB3125574 mentions a known problem using robocopy, but with a different symptom.  My money says this subdirectory behaviour is another problem in this "convenience" rollup, which has so far been pretty inconvenient for me.

    Thursday, May 4, 2017 5:22 PM