Robocopy - not providing destination in log output

Discussion in 'Scripting' started by JMic, Jun 18, 2009.

  1. JMic

    JMic Guest

    I am working with Robocopy to copy and move multiple files to multiple
    directories. All is working well except for the logging. I am able to get the
    log to output the source info but cannot get it to output the destination
    directory without adding the job summary. I do not want to include the job
    summary as this provides to much information for my logging requirements. I
    don't want to move away from Robocopy just because of this one missing piece
    but simpler apps like XCopy have this ability. I have tried the /fp switch
    but this still does not list the destination directory.
    JMic, Jun 18, 2009
    1. Advertisements

  2. The destination directory is shown right up the top. It is the same for each
    and every file:
    Source : h:\
    Dest : d:\HulDisk\

    If you want to show it for every copied file then you could write a simple
    little script that changes this log file line:
    New Dir 8 h:\WINDOWS\system32\oobe\regerror\
    into this one:
    New Dir 8 h:\WINDOWS\system32\oobe\regerror\
    Pegasus [MVP], Jun 18, 2009
    1. Advertisements

  3. JMic

    JMic Guest

    I am sorry but I am not understanding what you are referring to when you say
    "The destination directory is shown right up the top". Are you referring to
    what is reported in the job summary or the job header? I have seen this in
    the job summary but do not want all of the other information that comes with
    adding this. Clearly the information is available through Robocopy but how do
    I extract/parse this information into a simple log file? Here is a copy of
    the syntax I am using currently:
    echo %time%___%yr%_%mth%_%day% >>TodaysPages.log
    C:\Utilities\robocopy C:\TEMP C:\TEMP\PrintSites na*.pdf /NP /R:3 /W:3 /IS
    /IT /NP /NC /NS >>TodaysPages.log /NDL /NJH /NJS /R:3 /W:3

    The log file results of this are:


    JMic, Jun 19, 2009
  4. I recommend you modify your command by ommitting the following switches:
    - The second /np (it's duplicated)
    - The second /r:3 (it's duplicated)
    - The second /w:3 (it's duplicated)
    - /njh (so that you can see the header).
    You will then see the following report:
    ROBOCOPY :: Robust File Copy for Windows :: Version XP010
    Started : Fri Jun 19 13:00:37 2009
    Source : C:\MYOB105\
    Dest = d:\Fri\ *** This is the target folder ***
    Files : *.exe
    Options : /NS /NC /NDL /NJS /COPY:DAT /NP /IS /IT /R:3 /W:3

    If you don't want the header in your log file then you can write a simple
    script that does the following:
    - It reads the header
    - It notes the target folder
    - It writes the names of all copied files to a second log file, complete
    with the target folder name on each line.
    Pegasus [MVP], Jun 19, 2009
  5. JMic

    JMic Guest

    I was affraid of this being the only option. Yes, what you suggest is
    possible but only with additional coding and massaging of the original log
    file output. I was hoping there would be something much simpler, like the
    switch in XCopy that turns on the full file path showing both source and
    destination without any additional coding/data massaging.

    Thanks for the cleanup tips. I will implement these immediatly. If you or
    others have any other suggestions as to how to proceed - please no VBS or
    Perl suggestions as I am not well versed in either to make the switch, I
    would be gratefull.

    JMic, Jun 19, 2009
  6. I'm somewhat baffled. People who post questions in a *scripting* newsgroup
    are usually after some scripting solution, yet you specifically do not want
    such a solution. In this case it might be better for you to repost your
    question in a general type newsgroup (e.g. windowsxp.general) because you're
    after a command that will combine the robustness of robocopy with the output
    format of xcopy. Perhaps xxcopy.exe?

    Anyway, I recommend you have a closer look at VB Scripts. They are a very
    powerful solution for a great many problems. In your case a handful of lines
    would do pretty much what you need when invoked like this:
    cscript //nologo c:\Jmic.vbs < c:\robocopy.log > c:\robocopy.txt

    [01] Set oInput = WScript.StdIn
    [02] sDest = ""
    [03] While Not oInput.AtEndOfStream
    [04] sLine = oInput.ReadLine
    [05] If sDest = "" Then
    [06] p = InStr(1, sLine, "Dest = ", 1)
    [07] If p > 0 Then
    [08] sSource = Mid(sPrev, InStr(sPrev, ":") + 2)
    [09] sDest = Mid(sLine, InStr(sLine, "=") + 2)
    [10] End If
    [11] sPrev = sLine
    [12] Else
    [13] If InStr(sLine, "\") > 0 Then WScript.Echo pad(sLine, sSource,
    [14] End If
    [15] Wend
    [16] oInput.Close
    [18] Function pad (sString, sFrom, sTo)
    [19] sString = LTrim(Replace(sString, vbTab, ""))
    [20] If Len(sString) < 38 _
    [21] Then sSpacer = Space(38 - Len(sString)) Else sSpacer = " "
    [22] pad = sString & sSpacer & sTo & Mid(sString, Len(sSource)+1)
    [23] End Function
    Pegasus [MVP], Jun 19, 2009
  7. JMic

    JMic Guest

    I must respectfully disagree with you on this last comment. I consider a
    batch file to be a form of scripting and invoking a Microsoft supplied
    command line tool to be a part of that. My main concern was having to either
    move away from an existing, working script (Batch file) servicing a large
    production need for only logging reasons or find that I have missed something
    with the current script/command line tools. I am not sure if this would be
    considered ignorance or bad etiquette on my part though. :)

    I am working on but have not graduated to using VB Scripts. When I get to
    the same comfort level as I am with batch files, I will no doubt be
    converting many of my current batch files to VB.

    Thanks for the sample script. I will take this into the migration from batch
    files to VBS shortly.


    JMic, Jun 19, 2009
  8. I don't believe in converting batch files to VB Script files. Batch files
    tend to be good at some things and lousy at others, and vice versa. String
    manipulation is far more powerful and robust in VB Scripts than in batch
    files. Performing everyday admin tasks such as copying/backing up files
    takes far less effort in batch files than in VB Script files.

    You could massage your robocopy log file with a batch file but it would be
    painful, fragile and probably quite slow. With VB Scripts its easy - just an
    exercise in basic string manipulation.
    Pegasus [MVP], Jun 19, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.