copy files with crash

H

horst engel

I have a big partition with thousands of files to transfer to another
partition on another disk.
So I copied all files from the first disk and pasted them to the second
one with xcopy:
XXCOPY.EXE "H:\backup\*.*" "G:\" /BU /V /oNXXcopyErr.log /EC
Everything was going well when suddenly I had a crash and 3 partitions
out of 5 where completely destroyed!
The XXcopyErr.log file has also been destroyed.
I had a recent backup, so everything was ok again after an hour.
I made the same copy again and got exactly the same crash.
This probably means that one of the thousands files is damaged and
causes the crash.
The scandisk didn't show any problem.
Is there a way to find out which file is damaged without danger of crashing?
Thank you
Horst
 
P

Pegasus \(MVP\)

horst engel said:
I have a big partition with thousands of files to transfer to another
partition on another disk.
So I copied all files from the first disk and pasted them to the second
one with xcopy:
XXCOPY.EXE "H:\backup\*.*" "G:\" /BU /V /oNXXcopyErr.log /EC
Everything was going well when suddenly I had a crash and 3 partitions
out of 5 where completely destroyed!
The XXcopyErr.log file has also been destroyed.
I had a recent backup, so everything was ok again after an hour.
I made the same copy again and got exactly the same crash.
This probably means that one of the thousands files is damaged and
causes the crash.
The scandisk didn't show any problem.
Is there a way to find out which file is damaged without danger of crashing?
Thank you
Horst

Try xcopy.exe instead of xxcopy:

xcopy "H:\backup\*.*" "G:\" /r /d /c /h /e /v /y 1>c:\copy.log 2>&1

Chances are that xcopy won't crash. If it does then you should
examine the log file.

Another method is based on a process of elimination:

XXCOPY.EXE "H:\backup\A*.*" "G:\" /BU /V /oNXXcopyErr-A.log /EC
 
N

NewScience

Have you done a CHKDSK on both drives prior to the XCOPY do make sure that
they are in order?
Everything was going well when suddenly I had a crash and 3 partitions out
of 5 where completely destroyed!

Did you leave something out? You were copying from H:\... to G:\.... Where
did the three partitions come in out of 5. How?
 
H

horst engel

Try xcopy.exe instead of xxcopy:

xcopy "H:\backup\*.*" "G:\" /r /d /c /h /e /v /y 1>c:\copy.log 2>&1

Chances are that xcopy won't crash. If it does then you should
examine the log file.

Another method is based on a process of elimination:

XXCOPY.EXE "H:\backup\A*.*" "G:\" /BU /V /oNXXcopyErr-A.log /EC
Thank you.
I tried xcopy but I had the same crash!
I understand your 2nd suggestion, but I hoped to find some more
practical solution.
As I am usually not very lucky, I bet the faulty file will be something
like zipfix.exe!
Horst
 
H

horst engel

Yes, run CHKDSK on both drives and found no problem (actually only with
/F, as /R would require probably a day or so).
The crash destroyed C:, D: (containing Windows 2000) and E:.
F: doesn't show any problem and the partition G: was OK but everything
was deleted, so I don't know at which file I have the problem.
The source H: is on a second disk.
Satisfied? :->
Horst
 
V

VideoReDo Sucks

horst engel said:
I have a big partition with thousands of files to transfer to another
partition on another disk.
So I copied all files from the first disk and pasted them to the second
one with xcopy:
XXCOPY.EXE "H:\backup\*.*" "G:\" /BU /V /oNXXcopyErr.log /EC
Everything was going well when suddenly I had a crash and 3 partitions
out of 5 where completely destroyed!
The XXcopyErr.log file has also been destroyed.
I had a recent backup, so everything was ok again after an hour.
I made the same copy again and got exactly the same crash.
This probably means that one of the thousands files is damaged and
causes the crash.
The scandisk didn't show any problem.
Is there a way to find out which file is damaged without danger of crashing?
Thank you
Horst

I have seen this behavour when using large hard disks and 48-bit LBA was NOT
enabled.
 
H

horst engel

I have seen this behavour when using large hard disks and 48-bit LBA was NOT
enabled.
You are right: LBA is not enabled!
But please tell me: till yesterday I had no problem with my disks: how
was this possible even if LBA was not enabled?
Horst
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Top