ms-dos copy command

[doeray]

Hello All,  I am a newbie and I have some strange errors.  One of my end users are using the dos copy command on a windows 2000 server copying to a windows 2003 server.  When he copies  a text file from one server to the other, some of the data is being corrupted.  It normally is just 1 0r 2 characters that change.  This text file is then encrypted to one of our clients but they've been complaining that we are sending them bad data.  This process is normally automated and runs by itself.  We may run this process 50 times and get 5 or 6 bad copies.  Have anyone ever heard of anything like this, we called MS and they did not really have any answers.  If the file has a "." it will be changed to a "/" or vise versa.  I am at my wits in because we can not find the source of the problem.  Everyone thinks its the copy command, we even substituted to the move command and it ran fine for 2 weeks and now we just found out that we have sent them another bad file.  We are grasping at straws here.  If anyone has a different solution or heard of this before please let me know.
This is what MS said:
Brief summary of the issue

=====================

<> You have a job - which uses xp_cmdshell to copy a file from one folder to another (on the same server). The job uses UNC paths and not relative paths ie xp_cmdshell copy \\server\folder \\server\folder

<> Intermittently you see some characters in the file are changed - no junk characters but for some records '.' becomes '/'. You have also seen instances of some number being partially modified (2156 became 8156).

<> Issue is intermittent - not reproducible at will.

<> You have used ‘move’ instead of ‘copy’ and haven’t seen any issues thereafter.

 

Action plan

==========

If you remember one thing that we discussed was to use relative paths instead of UNC paths and see if that makes any difference ie ie xp_cmdshell copy c:\folder_name\abc.txt D:\folder_name\xyz.txt

Additionally I would like to run the copy command  without xp_cmdshell (creating a job /batch file and schedule it using Windows task scheduler) – just to be sure that xp_cmdshell is not changing the behavior.

Any other suggestions will help.
Thanks
Doeray

[dahlarbear]

Please note the ASCII representation of "." and "/" are only a bit off from one another.

    ASCII_Char    Octal     Binary
    .                     56         00101110
    /                     57         00101111

Suggest you stress test the system memory of both systems using a reliable standalone memory test program such as MemTest86 (www.memtest86.com).  A problem with memory (or the memory subsystem) could modify the data passed through it.

You may also have to verify the integrity of the entire data path between the Windows 2000 Server to Windows 2003 Server system to see if bits are intermitently being dropped and/or added.

I'm assuming this isn't a DOS copy command problem.

[Sidewinder]

The copy command has a /v switch for verifying the output data is written correctly. It may slow down the copy operation.

Additionally I would like to run the copy command  without xp_cmdshell (creating a job /batch file and schedule it using Windows task scheduler)

The command shell acts as the interpreter for batch files. Windows will open a command shell whenever a batch file is run, the scheduler and the run box are not exceptions.

You can however bypass the command shell by using any of the windows script languages (vbscript, jscript, rexx, python and many more)

The is a vbscript solution:

Code: [Select]

Const FOF_CREATEPROGRESSDLG = &H0&

strTargetFolder = "D:\Scripts"                                               

Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.NameSpace(strTargetFolder)

objFolder.CopyHere "C:\Scripts\*.*", FOF_CREATEPROGRESSDLG

In this example, d:\scripts is the target folder and c:\scripts is the source folder. Save the script with a vbs extension and run from the command prompt as cscript scriptname.vbs

PS. The progress bar is built into the CopyHere method.

 

Note: script uses mapped drives but should work with UNC tagging also