copy files with crash

  • Thread starter Thread starter horst engel
  • Start date Start date
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
 
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
Click to expand...

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
 
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!
Click to expand...

Did you leave something out? You were copying from H:\... to G:\.... Where
did the three partitions come in out of 5. How?
 
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
Click to expand...
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
 
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
 
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
Click to expand...

I have seen this behavour when using large hard disks and 48-bit LBA was NOT
enabled.
 
I have seen this behavour when using large hard disks and 48-bit LBA was NOT
enabled.
Click to expand...
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
 
Back
Top