locked
Script Wont Copy Files Over RRS feed

Answers

  • My final question is, "Are the files being processed in some way in the transfer or just being copied?"  That is, are they changed in any way during the process?  Does the extension of the file get changed or the size change?  Knowing that might permit us to suggest other ways to accomplish the transfer beside using the executable that no longer works correctly.

    I reread your original posting and wonder if an XCOPY with a /D switch might not do the work, instead of the utility.  Using the /S switch might also remove the need to name each and every sub location, that is, ...

    @echo off
      NET USE N: \\domain\mbs
      pushd
    n:\mbs003
     
    xcopy *.* c:\mbs\ /d /s
      popd
      net use n: /delete

    That might, emphasis might, do the job without resorting to the unsupported utility.


    Tom Lavedas
    Tuesday, April 26, 2011 8:10 PM

All replies

  • This seems to be invoking some process called mbsupdat, which is specific to your application.  AFAIK, it is not a standard Windows utility.  Therefore, I doubt if anyone here is going to be able to help you - unless mbsupdat is a batch file in the mbs\util folder.  Then we would need to see the contents of that batch procedure.  If it is a utility associated with some particular application you are running, then refer to the documentation for that application or contact its vendor for help.
    Tom Lavedas
    Thursday, April 21, 2011 6:49 PM
  • That's the bad part for me is that there was hardly any documentation in place here for the in house apps and procedures and most people here are not IT saavy except for AutoCad. I wasn't sure if the /a did anything that would prevent the copying of new folders or file names.

     

     

     

    Thursday, April 21, 2011 6:53 PM
  • You can always try to see if it will give you some on-line help with a /? switch, as in (at the command prompt - Run "cmd /k"))

    C:\>cd mbs\util
    C:\>mbsupdat /?

    And/Or possibly do a DIR to find out what kind of a file it is.


    Tom Lavedas
    Thursday, April 21, 2011 7:03 PM
  • I found another script that may also do the job...investigating...will report findings soon.
    Thursday, April 21, 2011 7:10 PM
  • I can shed some light on this now...

    I added this line because since the directory didn't exist, it wasn't copying over:

    md c:\mbs\doc2\UPDATE_INPUT

    I re-ran the script and it created the folder BUT it would not copy the files over from this command:

    c:\mbs\util\mbsupdat n:\mbs003\doc2\UPDATE_INPUT\*.* c:\mbs\doc2\UPDATE_INPUT  /a

    I thought it could be a permissions issue but doesn't seem to be...does that help in helping me find a solution here?

    Thanks...
    Brian

     

    Thursday, April 21, 2011 8:49 PM
  • Anyone have any other thoughts on this?
    Tuesday, April 26, 2011 7:16 PM
  • Hi,

    As Tom said, you will need to pursue help from whoever wrote the program "c:\mbs\util\mbsupdat.exe". That program is not a part of Windows and therefore we have no idea what it does or how to troubleshoot it.

    Bill

    Tuesday, April 26, 2011 7:30 PM
  • You're not giving anyone enough to go on.  You never answered the questions about what "mbsupdat" was.  Is it an executable?  Is it a batch procedure? Who supplies it?  What kind of documentation do you have on it?  Also, what kind of files is it trying to transfer?  Are they hidden per chance?

    The basic problem is you are working with a non-standard application on systems that we have no way of troubleshooting.  Without a lot more information, I don't see how anyone is going to be able to provide anything that is really helpful.  Sorry.


    Tom Lavedas
    Tuesday, April 26, 2011 7:33 PM
  • Well, I am a novice at this so wasn't sure if what I discovered had anything to do with that "mbsupdat.exe" or not...since I was able to add the line "md c:\mbs\doc2\UPDATE_INPUT" and the files still didn't copy with the "c:\mbs\util\mbsupdat n:\mbs003\doc2\UPDATE_INPUT\*.* c:\mbs\doc2\UPDATE_INPUT /a" line, I thought it could be another issue.

    Sadly, the person who made the original "mbsupdat.exe" was fired and doesn't return phone calls or emails anymore...so I could be stuck...

    Brian

     

    Tuesday, April 26, 2011 7:37 PM
  • My final question is, "Are the files being processed in some way in the transfer or just being copied?"  That is, are they changed in any way during the process?  Does the extension of the file get changed or the size change?  Knowing that might permit us to suggest other ways to accomplish the transfer beside using the executable that no longer works correctly.

    I reread your original posting and wonder if an XCOPY with a /D switch might not do the work, instead of the utility.  Using the /S switch might also remove the need to name each and every sub location, that is, ...

    @echo off
      NET USE N: \\domain\mbs
      pushd
    n:\mbs003
     
    xcopy *.* c:\mbs\ /d /s
      popd
      net use n: /delete

    That might, emphasis might, do the job without resorting to the unsupported utility.


    Tom Lavedas
    Tuesday, April 26, 2011 8:10 PM
  • the title of this entry needs to be more descriptive.
    Tuesday, April 26, 2011 8:45 PM
  • Thanks for all of the tips...nothing helped in this situation...I never could find out what that mbsupdat did nor could I find the source code or contact the original script writer...with that said, I may look at writing a brand new script...basically, it just needs to copy everything from a sherver share to the local C drive of the end user...nothing more, nothing less.
    Monday, May 9, 2011 1:18 PM
  • That's what I supposed and offered last Tuesday.  To repeat, ...

    @echo off
      NET USE N: \\domain\mbs
      pushd
    n:\mbs003
     
    xcopy *.* c:\mbs\ /d /s
      popd
      net use n: /delete


    Tom Lavedas
    Monday, May 9, 2011 1:43 PM