cmd copy command dropped file records

June 1, 2011 at 07:08:42
Specs: Windows XP
Copied TXT file to backup directory and only last 600 records of 1300 record file existed in backup directory. First 600 records were dropped from copy. The TXT file contained very common data - mostly numbers - financial information - no special characters - each line of text ended in CRLF carriage return line feed

See More: cmd copy command dropped file records

Report •

#1
June 1, 2011 at 11:32:59
First, what version of DOS do you have? type ver and write down the info on-screen. If you have DOS 5 or above, type EDIT at command prompt to open the text editor. Find and open the original text file. (This next part rides on how much memory you have) Start from the top and hold the <SHIFT> key. then hold the down arrow until you reach the bottom of the screen. (This can take a while) hit <ALT> and choose <EDIT>, then from the submenu, <COPY>. If you get the "Not enough memory to preform this operation" screen, go to my next paragraph. If it goes alright, then open a new text file (Your old one will still be there) in the backup directory and go through the submenu under <EDIT> and choose <PASTE>. Your text file should be there while keeping the old file intact. Most likley what happened was that the text file was put into memory, but it didn't have enough to store the first 600 records.

Try running a memory cleaning program such as, in DOS 6.2, MEMMAKER

If your running DOS 4 or lower, you can't use EDLIN for the copy and paste command. Can you copy the file to some other directory? How long since you've run a disk checking program? (CHKDSK, SCANDISK) You could have errors keeping you from writing the file to the Hard Disk.
P.S> this might be a little too extensive, but just my thoughts! ;->


Report •

#2
June 1, 2011 at 12:31:27
Has nothing to do with amount of memory.
The copy command copies larger files in parts til it's completed.
Simply use the copy command with /b and see what happens.

copy /b source_file.txt destination_file.txt

Click Here on HowTo ask good Question to get best Help
Let us know, if the problem is solved !!!


Report •

#3
June 1, 2011 at 13:17:25
Memory would not be an issue as the file was only 2000 records of 80 bytes. What happened was the the execution of the COPY command caused the first 600 records to be somehow dropped, the destination file had only the last 700 records of the 1300 record file. I have never seen where COPY has done this- see script

for /f "Tokens=1-4 Delims=/ " %%i in ('date /t') do set dt=%%l%%j%%k
copy /b /v /y E:\QModules\Data\Output\gppdmuftp.txt E:\FairFaxFTP\FTPFile\gppdmuftp-%dt%.txt
copy /b /v /y E:\QModules\Data\Output\gppdmuftp.txt E:\FairFaxFTP\FTPFile\gppdmuftp.txt
2nd copy failed to copy all lines


Report •

Related Solutions

#4
June 1, 2011 at 21:50:46
Is this XP command prompt?

Is it possible the files are being overwritten instead of dropped? Do a dir/? at command prompt and see what it says about the /y switch in batch files.

Caramel--the devil's chocolate.


Report •

#5
June 2, 2011 at 11:57:20
I don't know what you mean by XP command prompt. We run this script each day and it runs the vert basic DOS COPT command.

In the script the first copy takes the file to a destination file name that includes the date so that could be over-ridden but we only run once daily. The second copy copies the file to a specific file name. This file is supposedly deleted by another secondary process later in the day. But the file could get overwritten.


Report •

#6
June 2, 2011 at 19:38:37
Command prompt is what you get when you go to START--PROGRAMS--ACCESSORIES--COMMAND PROMPT (I think that's where it's at. I moved mine.) It gives you the dos screen and works exactly like dos, although some commands are updated. Some dos purists get offended if you call XP's command prompt 'dos'.

Caramel--the devil's chocolate.


Report •

#7
June 3, 2011 at 03:00:01
Yes quite correct NT Command Prompt CMD.EXE IS NOT MS-DOS and never will be, this is a Programming Question.................

Report •

#8
June 4, 2011 at 02:10:23
Something (I think) not picked up above is the number of files being copied.

'True' dos can have problems when there is a large number in a directory/folder.

e.g. files can be written to a directory, then not 'seen'. Although they are there and not lost.

This may not apply to this problem as WXP might be involved, but thought this worth mentioning.

Good Luck - Keep us posted.


Report •

#9
June 8, 2011 at 08:43:45
The previous copy step was copying multiple files - we called a ROBOCOPY - but the step that failed was a single COPY of one file. It was a pretty basic COPY command from a Windows XP server. It has not happened before or since. The easiest explanation is space, but that was not the issue and ensuing copies worked fine. My thought was that the data file contained some special character that signaled this to be an end of file. If so, the COPY may have kept going and basically copied the secondary part of the input file over/replacing the output file.

Report •

#10
June 8, 2011 at 14:16:53
If you do a binary copy, special characters doesn't matter.

You are expecting our help, we are expecting your response !!!


Report •

#11
July 18, 2011 at 03:52:32
juts redirect your command details to file .txt

example::
C:\Documents and Settings\My Documents> dir >c://example.txt

thank open your c: directory to retrieve file example.txt.


Report •

#12
July 18, 2011 at 05:18:21
We did direct the output to a log file but of course the details of the robocopy confused the heck out of us. It turns out that the software vendors (who created the initial file) created two copies of the data and backed up one file to our backup directories (it was a full file), but backed up the second file to a different set of directories (this file was already truncated before the copy). Because we focused on the initial backup file, and subsequent files based on this data we got confused. We thought the second COPY had done a truncation. However the FROM file was already truncated due to vendor software issues. This FROM file was not accessible by our security authorizations and was deleted by their script. Sorry for wasting everyone's time. This problem record can be considered closed.

Report •

Ask Question