locked
Robocopy problem

    Question

  • I have a server that copies all of the files I need to backup from various servers onto its local disk using Robocopy. I wrote a batch script that has been running perfectly for several years on Server 2003.

    I recently upgraded all of the servers to 2008 R2 full release (clean installs). Now when I copy from the Users folder on one of the servers (it is shared out as Docsnsets) (used to be Documents & Settings on the old server), using this instruction:

    robocopy /e /r:1 /tee /log:robocopy_driveS_New.log \\Support2\Docsnsets d:\Backups\Thursday\Docsnsets

    I get this in my log:


    -------------------------------------------------------------------------------
       ROBOCOPY     ::     Robust File Copy for Windows                             
    -------------------------------------------------------------------------------

      Started : Fri Dec 04 10:55:51 2009

       Source : \\Support2\Docsnsets\
         Dest : d:\Backups\Thursday\Docsnsets\

        Files : *.*
        
      Options : *.* /TEE /S /E /COPY:DAT /R:1 /W:30

    ------------------------------------------------------------------------------

                        1 \\Support2\Docsnsets\
         New File         174 desktop.ini
      0% 
    100% 
       New Dir          7 \\Support2\Docsnsets\Administrator\
         New File       1.0 m NTUSER.DAT
      0% 
     25% 
     50% 
     75% 
    100% 
         New File      262144 ntuser.dat.LOG1
      0% 
     50% 
    100% 
         New File           0 ntuser.dat.LOG2
    100% 
         New File       65536 NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TM.blf
      0% 
    100% 
         New File      524288 NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000001.regtrans-ms
      0% 
     25% 
     50% 
     75% 
    100% 
         New File      524288 NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000002.regtrans-ms
      0% 
     25% 
     50% 
     75% 
    100% 
         New File          20 ntuser.ini
      0% 
    100% 
       New Dir          0 \\Support2\Docsnsets\Administrator\AppData\
       New Dir          2 \\Support2\Docsnsets\Administrator\AppData\Local\
         New File       57560 GDIPFONTCACHEV1.DAT
      0% 
    100% 
         New File      776324 IconCache.db
      0% 
     33% 
     67% 
    100% 
       New Dir          2 \\Support2\Docsnsets\Administrator\AppData\Local\Application Data\
         New File       57560 GDIPFONTCACHEV1.DAT
      0% 
    100% 
         New File      776324 IconCache.db
      0% 
     33% 
     67% 
    100% 
       New Dir          2 \\Support2\Docsnsets\Administrator\AppData\Local\Application Data\Application Data\
         New File       57560 GDIPFONTCACHEV1.DAT
      0% 
    100% 
         New File      776324 IconCache.db
      0% 
     33% 
     67% 
    100% 
       New Dir          2 \\Support2\Docsnsets\Administrator\AppData\Local\Application Data\Application Data\Application Data\
         New File       57560 GDIPFONTCACHEV1.DAT
      0% 
    100% 
         New File      776324 IconCache.db
      0% 
     33% 
     67% 
    100% 
       New Dir          2 \\Support2\Docsnsets\Administrator\AppData\Local\Application Data\Application Data\Application Data\Application Data\
         New File       57560 GDIPFONTCACHEV1.DAT
      0% 
    100% 
         New File      776324 IconCache.db
      0% 
     33% 
     67% 
    100% 
       New Dir          2 \\Support2\Docsnsets\Administrator\AppData\Local\Application Data\Application Data\Application Data\Application Data\Application Data\
         New File       57560 GDIPFONTCACHEV1.DAT
      0% 
    100% 
         New File      776324 IconCache.db
      0% 
     33% 
     67% 
    100% 
       New Dir          2 \\Support2\Docsnsets\Administrator\AppData\Local\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\
         New File       57560 GDIPFONTCACHEV1.DAT
      0% 
    100% 
         New File      776324 IconCache.db
      0% 
     33% 
     67% 
    100% 
       New Dir          2 \\Support2\Docsnsets\Administrator\AppData\Local\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\
         New File       57560 GDIPFONTCACHEV1.DAT
      0% 
    100% 
         New File      776324 IconCache.db
      0% 
     33% 
     67% 
    100% 
       New Dir          2 \\Support2\Docsnsets\Administrator\AppData\Local\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\
         New File       57560 GDIPFONTCACHEV1.DAT
      0% 
    100%  
        
    And this just goes on and on and nothing is actually copied.


    Correction. Files are copied, but the path / filename is so long that it appears that nothing is in the destination folder (the details can't be displayed). I also can't delete the destination folder for the same reason. I have tried deleting it from Windows Explorer with shift so that it doesn't go ito the Recycle Bin and from a DOS prompt, but I still can't get rid of it. 

    • Changed type David Shen Monday, December 07, 2009 6:09 AM
    Friday, December 04, 2009 11:20 AM

Answers

  • I had to raise an incident. The answer is to add the /XJ switch to the Robocopy instruction. This excludes Junctions, both Files and Directories (I thought they were supposed to be called Folders these days).

    This exact issue is referred to in:

    http://en.wikipedia.org/wiki/NTFS_junction_point

    The General paragraph says that a junction was added in Vista and Win7 (and Server 2008 R2 I imagine) for backward compatibility - just my luck that it created backward incompatibility!
    • Marked as answer by troy99 Tuesday, December 15, 2009 4:14 PM
    Tuesday, December 15, 2009 4:14 PM

All replies

  • Hello troy99,

     

    In order to help you troubleshoot the issue, I build a test environment to test with your same robocopy command, and I can users data from Windows Server 2008/ 2008 R2 to Windows Server 2008 R2 computer with success.

     

    From your further description, it seems that you want to delete these copied folder on destination Windows Server 2008 R2. To do it, please logon the destination server locally with its built-in administrator account, we may need to verify that the logon user session have enough privilege to perform the deletion action. Meanwhile, please verify that the folder that you want to delete is not in use when you perform the deletion action.


    Hope it helps. Thanks.

    For the file deletion issue, please also check if the directory path is over 256 character strings in the MAX_PATH. Win32 programs are limited to a 256-character string size limit because of the MAX_PATH variable. When the path length exceeds this length, you may receive error messages when accessing it. Please consider using subst tool to map the long path to a drive letter and then try to delete the files again.


    Path too long error message when exceeding MAX_PATH

    http://support.microsoft.com/?id=177665

     


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, December 07, 2009 6:10 AM
  • Hi David,

    Thanks for your reply.

    The only way I have found to delete the file is to format the disk. Fortunately, there is nothing else on it, so this is not a problem and when the copy issue is resolved, that won't arise.

    I mentioned the delete problem simply because it is further evidence that the file & folder names are corrupt with \Application Data\Application Data\Application Data\Application Data\..... being inserted in the target path by Robocopy. This is the real problem and I can't see how to resolve it.

    The source file is not corrupt. Firstly I can copy it correctly with Windows Explorer (but this doesn't help for my overnight backups) and secondly for testing I am using the 'Users' folder of a newly-created user that has just one small text file in it.

    Best regards, Gordon
    Monday, December 07, 2009 9:41 AM
  • The syntax looks a little wierd > Syntax| ROBOCOPY source_folder destination_folder [file(s)_to_copy] [options] or for example see below

    "robocopy" "C:\Users\\Documents" "z:\Documents" /COPY:DAT /IA:RASHNTCEO /s /V /TS /FP /R:5 /W:0 /TBD /ETA /LOG:"C:\Migrate13-10.log" /TEE




    -Ivan

    Ivan Sanders My LinkedIn Profile, My Blog, @iasanders.
    Monday, December 07, 2009 10:30 AM
  • @ Ivan,

    Thanks for your reply. However, that example is lifted directly from my batch file which has worked perfectly on Server 2003 for a couple of years.

    @ David,

    Further info. Because my backup script isn't working, I copied the data from one server to the other using Windows Explorer and got this error:

    "The file name(s) would be too long for the destination folder. You can shorten the file name and try again, or try a location that has a shorter path."

    There were several files for a number of users that gave this error, and some of the file names were repeated several times:

    User 1:
    23YRRK82
    23YRRK02
    67NGU7JV
    NSHCRFX9 (Repeated x2 times)

    User 2:
    B1MTF2Q4 (repeated more than 10 times)
    DK4REA7H (more than 10 times)
    PRGS1ERS (more than 10 times)
    SV8K1ASP (more than 10 times)

    User 3:
    059HHXGZ (x3 times)
    PF62J8KB (x3 times)
    RX6F99ET
    X9Y02B59

    Because of the corruption, I can't find where these files are (!)

    Are they system files, and do you know what they are, where I would find them and how to get rid of them please?

    Monday, December 07, 2009 10:56 AM
  • Hi troy99,

     

    It is hard to say what these users file name refer to.

     

    As you may encounter the error:

     

    "The file name(s) would be too long for the destination folder. You can shorten the file name and try again, or try a location that has a shorter path."

     

    Those repeated file might be the source file when you copy them from. You may try workaround to create a mapped drive letter to map to the source folder to shorten the path. And then test to copy them.

     

    If the issue still continues, I would like to suggest that you contact local Microsoft Customer Service and Support (CSS). A dedicate support engineer can speak directly with you to analyze the problem in a more efficiently way.

     

    How and when to contact Microsoft Customer Service and Support

    http://support.microsoft.com/kb/295539

    Hope it helps.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by David Shen Thursday, December 10, 2009 9:54 AM
    • Unmarked as answer by troy99 Tuesday, December 15, 2009 4:11 PM
    Tuesday, December 08, 2009 7:37 AM
  • I had to raise an incident. The answer is to add the /XJ switch to the Robocopy instruction. This excludes Junctions, both Files and Directories (I thought they were supposed to be called Folders these days).

    This exact issue is referred to in:

    http://en.wikipedia.org/wiki/NTFS_junction_point

    The General paragraph says that a junction was added in Vista and Win7 (and Server 2008 R2 I imagine) for backward compatibility - just my luck that it created backward incompatibility!
    • Marked as answer by troy99 Tuesday, December 15, 2009 4:14 PM
    Tuesday, December 15, 2009 4:14 PM
  • Hi troy99,

    Glad to hear you have found the cause. and thank you for the sharing on Junction point.

    Again, if you have other question, please feel free to post here.
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, December 16, 2009 3:16 AM