Archived from groups: microsoft.public.windowsxp.general (More info?)

I have a problem when copying large files (50MB+):
Both the DOS copy /B and the drag/drop or copy/paste methods in explorer
result always in a slightly different (corrupt) copy without generating any
error message. Aparently everything is fine but when checking on binary
level, there are differences. Depending on the application this result in
unreadble files.
The number of changed bytes is proportional to the length of the file.

Example: when I copy a file of about 300MB it results in a compare as follows:
> D:\>fc /B aa.ape bb.ape
> Comparing file aa.ape and BB.APE
> 0054204C: 7F 31
> 0054204D: D8 30
> 03DD478E: B8 F8
> 0B16184E: 7F AD
> 0B16184F: C4 0B
> 0BBC620C: CA 0D
> 0BBC620D: D7 F0
> 0BBC620E: C3 AD
> 0BBC620F: 7E 0B
> 0C6A00CC: 12 31
> 0C6A00CD: CA 30
> 0DE24C8C: E7 31
> 0DE24C8D: 5B 30
> 0DE24C8E: D2 71
> 0DE24C8F: 78 68
> 0E3D05CC: 1B 31
> 0E3D05CD: D9 30
> 0E3D05CE: 2E 71
> 0E3D05CF: 67 68
> 0FD1244C: 30 31
> 0FD1244D: DB 30
>
There are some patterns which repeat themselves. The sequence 30 31 hex
often appear in the adjacent positions xxxxxxxC xxxxxxxD, while 68 appears in
position xxxxxxxF.

I have 2 Harddisks but it does not matter which is source or destination, it
can also coincide. (I first noted it when nero in verification phase found
differences between source and masterized copy)

The errors do not occure when i use DOS copy in Windows started in save mode!

Therefore I exclude HW problems. (Anyway I already changed IDE cables and
run memtest). Also, updating the driver VIA 4in1 did not help.

please, help!

Archived from groups: microsoft.public.windowsxp.general (More info?)

"Berni" <Berni@discussions.microsoft.com> wrote in message
news:CD7445ED-5FF4-431D-828A-AECB2DF99BE6@microsoft.com...
> I have a problem when copying large files (50MB+):
> Both the DOS copy /B and the drag/drop or copy/paste methods in explorer
> result always in a slightly different (corrupt) copy without generating
any
> error message. Aparently everything is fine but when checking on binary
> level, there are differences. Depending on the application this result in
> unreadble files.
> The number of changed bytes is proportional to the length of the file.
>
> Example: when I copy a file of about 300MB it results in a compare as
follows:
> > D:\>fc /B aa.ape bb.ape
> > Comparing file aa.ape and BB.APE
> > 0054204C: 7F 31
> > 0054204D: D8 30
> > 03DD478E: B8 F8
> > 0B16184E: 7F AD
> > 0B16184F: C4 0B
> > 0BBC620C: CA 0D
> > 0BBC620D: D7 F0
> > 0BBC620E: C3 AD
> > 0BBC620F: 7E 0B
> > 0C6A00CC: 12 31
> > 0C6A00CD: CA 30
> > 0DE24C8C: E7 31
> > 0DE24C8D: 5B 30
> > 0DE24C8E: D2 71
> > 0DE24C8F: 78 68
> > 0E3D05CC: 1B 31
> > 0E3D05CD: D9 30
> > 0E3D05CE: 2E 71
> > 0E3D05CF: 67 68
> > 0FD1244C: 30 31
> > 0FD1244D: DB 30
> >
> There are some patterns which repeat themselves. The sequence 30 31 hex
> often appear in the adjacent positions xxxxxxxC xxxxxxxD, while 68 appears
in
> position xxxxxxxF.
>
> I have 2 Harddisks but it does not matter which is source or destination,
it
> can also coincide. (I first noted it when nero in verification phase found
> differences between source and masterized copy)
>
> The errors do not occure when i use DOS copy in Windows started in save
mode!
>
> Therefore I exclude HW problems. (Anyway I already changed IDE cables and
> run memtest). Also, updating the driver VIA 4in1 did not help.
>
> please, help!

I suggest you run the following batch file from a Command Prompt:

@echo off
xcopy /v /b "SourceFolder\SourceFile" "DestFolder\DestFile"
echo Errorlevel for xcopy was %ErrorLevel%
pause
fc /b "SourceFolder\SourceFile" "DestFolder\DestFile" | more
pause

xxcopy /v /b "SourceFolder\SourceFile" "DestFolder\DestFile"
echo Errorlevel for xxcopy was %ErrorLevel%
pause
fc /b "SourceFolder\SourceFile" "DestFolder\DestFile" | more

While this might not solve your problem, it could shed some
light on your problem. xxcopy.exe is downloadable from various
sites.

Archived from groups: microsoft.public.windowsxp.general (More info?)

Pegasus (MVP) wrote:

> "Berni" <Berni@discussions.microsoft.com> wrote in message
> news:CD7445ED-5FF4-431D-828A-AECB2DF99BE6@microsoft.com...
>
>>I have a problem when copying large files (50MB+):
>>Both the DOS copy /B and the drag/drop or copy/paste methods in explorer
>>result always in a slightly different (corrupt) copy without generating
>
> any
>
>>error message. Aparently everything is fine but when checking on binary
>>level, there are differences. Depending on the application this result in
>>unreadble files.
>>The number of changed bytes is proportional to the length of the file.
>>
>>Example: when I copy a file of about 300MB it results in a compare as
>
> follows:
>
>>>D:\>fc /B aa.ape bb.ape
>>>Comparing file aa.ape and BB.APE
>>>0054204C: 7F 31
>>>0054204D: D8 30
>>>03DD478E: B8 F8
>>>0B16184E: 7F AD
>>>0B16184F: C4 0B
>>>0BBC620C: CA 0D
>>>0BBC620D: D7 F0
>>>0BBC620E: C3 AD
>>>0BBC620F: 7E 0B
>>>0C6A00CC: 12 31
>>>0C6A00CD: CA 30
>>>0DE24C8C: E7 31
>>>0DE24C8D: 5B 30
>>>0DE24C8E: D2 71
>>>0DE24C8F: 78 68
>>>0E3D05CC: 1B 31
>>>0E3D05CD: D9 30
>>>0E3D05CE: 2E 71
>>>0E3D05CF: 67 68
>>>0FD1244C: 30 31
>>>0FD1244D: DB 30
>>>
>>
>>There are some patterns which repeat themselves. The sequence 30 31 hex
>>often appear in the adjacent positions xxxxxxxC xxxxxxxD, while 68 appears
>
> in
>
>>position xxxxxxxF.
>>
>>I have 2 Harddisks but it does not matter which is source or destination,
>
> it
>
>>can also coincide. (I first noted it when nero in verification phase found
>>differences between source and masterized copy)
>>
>>The errors do not occure when i use DOS copy in Windows started in save
>
> mode!
>
>>Therefore I exclude HW problems. (Anyway I already changed IDE cables and
>>run memtest). Also, updating the driver VIA 4in1 did not help.
>>
>>please, help!
>
>
> I suggest you run the following batch file from a Command Prompt:
>
> @echo off
> xcopy /v /b "SourceFolder\SourceFile" "DestFolder\DestFile"
> echo Errorlevel for xcopy was %ErrorLevel%
> pause
> fc /b "SourceFolder\SourceFile" "DestFolder\DestFile" | more
> pause
>
> xxcopy /v /b "SourceFolder\SourceFile" "DestFolder\DestFile"
> echo Errorlevel for xxcopy was %ErrorLevel%
> pause
> fc /b "SourceFolder\SourceFile" "DestFolder\DestFile" | more
>
> While this might not solve your problem, it could shed some
> light on your problem. xxcopy.exe is downloadable from various
> sites.
>
Hi,

An alternative to xxcopy is Robocopy.

Robocopy.exe is in the free Windows Server 2003 Resource Kit:

http://www.microsoft.com/downloads [...] layLang=en

(The kit will install on WinXP or later, the individual files can
then be copied to another computer if needed)


See rktools.chm and robocopy.doc for documentation for Robocopy.exe.



--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/s [...] fault.mspx

Archived from groups: microsoft.public.windowsxp.general (More info?)

"Berni" <Berni@discussions.microsoft.com> wrote in message
news:CD7445ED-5FF4-431D-828A-AECB2DF99BE6@microsoft.com...
>I have a problem when copying large files (50MB+):
> Both the DOS copy /B and the drag/drop or copy/paste methods in explorer
> result always in a slightly different (corrupt) copy without generating
> any
> error message. Aparently everything is fine but when checking on binary
> level, there are differences. Depending on the application this result in
> unreadble files.
> The number of changed bytes is proportional to the length of the file.
>
> Example: when I copy a file of about 300MB it results in a compare as
> follows:
>> D:\>fc /B aa.ape bb.ape
>> Comparing file aa.ape and BB.APE
>> 0054204C: 7F 31
>> 0054204D: D8 30
>> 03DD478E: B8 F8
>> 0B16184E: 7F AD
>> 0B16184F: C4 0B
>> 0BBC620C: CA 0D
>> 0BBC620D: D7 F0
>> 0BBC620E: C3 AD
>> 0BBC620F: 7E 0B
>> 0C6A00CC: 12 31
>> 0C6A00CD: CA 30
>> 0DE24C8C: E7 31
>> 0DE24C8D: 5B 30
>> 0DE24C8E: D2 71
>> 0DE24C8F: 78 68
>> 0E3D05CC: 1B 31
>> 0E3D05CD: D9 30
>> 0E3D05CE: 2E 71
>> 0E3D05CF: 67 68
>> 0FD1244C: 30 31
>> 0FD1244D: DB 30
>>
> There are some patterns which repeat themselves. The sequence 30 31 hex
> often appear in the adjacent positions xxxxxxxC xxxxxxxD, while 68 appears
> in
> position xxxxxxxF.
>
> I have 2 Harddisks but it does not matter which is source or destination,
> it
> can also coincide. (I first noted it when nero in verification phase found
> differences between source and masterized copy)
>
> The errors do not occure when i use DOS copy in Windows started in save
> mode!
>
> Therefore I exclude HW problems. (Anyway I already changed IDE cables and
> run memtest). Also, updating the driver VIA 4in1 did not help.
>
> please, help!

Not sure whether the D: drive you indicate is local or network.

I had problems of a similar nature about 12 years ago with Netware "lite,"
which would randomly change bytes in large copied files. The destination
file would occasionally have bytes changed - always in the same files, same
byte-offset, and the changed-to pattern was always one of a small set of
rogue bytes.

As far as I'm aware, since Novell hasn't got back to me about it as
promised, they're still working on it....

Is there anything of this nature in your setup?

HTH

....Bill

Archived from groups: microsoft.public.windowsxp.general (More info?)

This is a problem, while rare, that is usually caused by network card drivers. Maybe Novell drivers were like Windows drivers.

--
--------------------------------------------------------------------------------------------------
http://webdiary.smh.com.au/archive [...] 01075.html
=================================================
"billious" <billious_1954@hotmail.com> wrote in message news:432613e3$0$12704$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
>
> "Berni" <Berni@discussions.microsoft.com> wrote in message
> news:CD7445ED-5FF4-431D-828A-AECB2DF99BE6@microsoft.com...
>>I have a problem when copying large files (50MB+):
>> Both the DOS copy /B and the drag/drop or copy/paste methods in explorer
>> result always in a slightly different (corrupt) copy without generating
>> any
>> error message. Aparently everything is fine but when checking on binary
>> level, there are differences. Depending on the application this result in
>> unreadble files.
>> The number of changed bytes is proportional to the length of the file.
>>
>> Example: when I copy a file of about 300MB it results in a compare as
>> follows:
>>> D:\>fc /B aa.ape bb.ape
>>> Comparing file aa.ape and BB.APE
>>> 0054204C: 7F 31
>>> 0054204D: D8 30
>>> 03DD478E: B8 F8
>>> 0B16184E: 7F AD
>>> 0B16184F: C4 0B
>>> 0BBC620C: CA 0D
>>> 0BBC620D: D7 F0
>>> 0BBC620E: C3 AD
>>> 0BBC620F: 7E 0B
>>> 0C6A00CC: 12 31
>>> 0C6A00CD: CA 30
>>> 0DE24C8C: E7 31
>>> 0DE24C8D: 5B 30
>>> 0DE24C8E: D2 71
>>> 0DE24C8F: 78 68
>>> 0E3D05CC: 1B 31
>>> 0E3D05CD: D9 30
>>> 0E3D05CE: 2E 71
>>> 0E3D05CF: 67 68
>>> 0FD1244C: 30 31
>>> 0FD1244D: DB 30
>>>
>> There are some patterns which repeat themselves. The sequence 30 31 hex
>> often appear in the adjacent positions xxxxxxxC xxxxxxxD, while 68 appears
>> in
>> position xxxxxxxF.
>>
>> I have 2 Harddisks but it does not matter which is source or destination,
>> it
>> can also coincide. (I first noted it when nero in verification phase found
>> differences between source and masterized copy)
>>
>> The errors do not occure when i use DOS copy in Windows started in save
>> mode!
>>
>> Therefore I exclude HW problems. (Anyway I already changed IDE cables and
>> run memtest). Also, updating the driver VIA 4in1 did not help.
>>
>> please, help!
>
> Not sure whether the D: drive you indicate is local or network.
>
> I had problems of a similar nature about 12 years ago with Netware "lite,"
> which would randomly change bytes in large copied files. The destination
> file would occasionally have bytes changed - always in the same files, same
> byte-offset, and the changed-to pattern was always one of a small set of
> rogue bytes.
>
> As far as I'm aware, since Novell hasn't got back to me about it as
> promised, they're still working on it....
>
> Is there anything of this nature in your setup?
>
> HTH
>
> ...Bill
>
>

Archived from groups: microsoft.public.windowsxp.general (More info?)

"David Candy" wrote:

> This is a problem, while rare, that is usually caused by network card drivers. Maybe Novell drivers were like Windows drivers.

No sorry, it is disk to disk, it happens even when creating a copy on the
same drive - any idea?

>
> --
> --------------------------------------------------------------------------------------------------
> http://webdiary.smh.com.au/archive [...] 01075.html
> =================================================
> "billious" <billious_1954@hotmail.com> wrote in message news:432613e3$0$12704$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> >
> > "Berni" <Berni@discussions.microsoft.com> wrote in message
> > news:CD7445ED-5FF4-431D-828A-AECB2DF99BE6@microsoft.com...
> >>I have a problem when copying large files (50MB+):
> >> Both the DOS copy /B and the drag/drop or copy/paste methods in explorer
> >> result always in a slightly different (corrupt) copy without generating
> >> any
> >> error message. Aparently everything is fine but when checking on binary
> >> level, there are differences. Depending on the application this result in
> >> unreadble files.
> >> The number of changed bytes is proportional to the length of the file.
> >>
> >> Example: when I copy a file of about 300MB it results in a compare as
> >> follows:
> >>> D:\>fc /B aa.ape bb.ape
> >>> Comparing file aa.ape and BB.APE
> >>> 0054204C: 7F 31
> >>> 0054204D: D8 30
> >>> 03DD478E: B8 F8
> >>> 0B16184E: 7F AD
> >>> 0B16184F: C4 0B
> >>> 0BBC620C: CA 0D
> >>> 0BBC620D: D7 F0
> >>> 0BBC620E: C3 AD
> >>> 0BBC620F: 7E 0B
> >>> 0C6A00CC: 12 31
> >>> 0C6A00CD: CA 30
> >>> 0DE24C8C: E7 31
> >>> 0DE24C8D: 5B 30
> >>> 0DE24C8E: D2 71
> >>> 0DE24C8F: 78 68
> >>> 0E3D05CC: 1B 31
> >>> 0E3D05CD: D9 30
> >>> 0E3D05CE: 2E 71
> >>> 0E3D05CF: 67 68
> >>> 0FD1244C: 30 31
> >>> 0FD1244D: DB 30
> >>>
> >> There are some patterns which repeat themselves. The sequence 30 31 hex
> >> often appear in the adjacent positions xxxxxxxC xxxxxxxD, while 68 appears
> >> in
> >> position xxxxxxxF.
> >>
> >> I have 2 Harddisks but it does not matter which is source or destination,
> >> it
> >> can also coincide. (I first noted it when nero in verification phase found
> >> differences between source and masterized copy)
> >>
> >> The errors do not occure when i use DOS copy in Windows started in save
> >> mode!
> >>
> >> Therefore I exclude HW problems. (Anyway I already changed IDE cables and
> >> run memtest). Also, updating the driver VIA 4in1 did not help.
> >>
> >> please, help!
> >
> > Not sure whether the D: drive you indicate is local or network.
> >
> > I had problems of a similar nature about 12 years ago with Netware "lite,"
> > which would randomly change bytes in large copied files. The destination
> > file would occasionally have bytes changed - always in the same files, same
> > byte-offset, and the changed-to pattern was always one of a small set of
> > rogue bytes.
> >
> > As far as I'm aware, since Novell hasn't got back to me about it as
> > promised, they're still working on it....
> >
> > Is there anything of this nature in your setup?
> >
> > HTH
> >
> > ...Bill
> >
> >
>

Archived from groups: microsoft.public.windowsxp.general (More info?)

Go to Device Manager, Disk Drives category, Double-Click your drive
From the details box click the Policies (TAB). Uncheck "Enable Write
Cache", Apply & then reboot and retry your copy operations. Also,
could you post which Vendor/Model (& Interface type) drive you're
having issues with.



"Berni" <Berni@discussions.microsoft.com> wrote in message
news:99B7A563-FFE5-4E99-A82F-8E97F55FAC5B@microsoft.com...
>
>
> "David Candy" wrote:
>
>> This is a problem, while rare, that is usually caused by network card
>> drivers. Maybe Novell drivers were like Windows drivers.
>
> No sorry, it is disk to disk, it happens even when creating a copy on the
> same drive - any idea?
>
>>
>> --
>> --------------------------------------------------------------------------------------------------
>> http://webdiary.smh.com.au/archive [...] 01075.html
>> =================================================
>> "billious" <billious_1954@hotmail.com> wrote in message
>> news:432613e3$0$12704$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
>> >
>> > "Berni" <Berni@discussions.microsoft.com> wrote in message
>> > news:CD7445ED-5FF4-431D-828A-AECB2DF99BE6@microsoft.com...
>> >>I have a problem when copying large files (50MB+):
>> >> Both the DOS copy /B and the drag/drop or copy/paste methods in
>> >> explorer
>> >> result always in a slightly different (corrupt) copy without
>> >> generating
>> >> any
>> >> error message. Aparently everything is fine but when checking on
>> >> binary
>> >> level, there are differences. Depending on the application this result
>> >> in
>> >> unreadble files.
>> >> The number of changed bytes is proportional to the length of the file.
>> >>
>> >> Example: when I copy a file of about 300MB it results in a compare as
>> >> follows:
>> >>> D:\>fc /B aa.ape bb.ape
>> >>> Comparing file aa.ape and BB.APE
>> >>> 0054204C: 7F 31
>> >>> 0054204D: D8 30
>> >>> 03DD478E: B8 F8
>> >>> 0B16184E: 7F AD
>> >>> 0B16184F: C4 0B
>> >>> 0BBC620C: CA 0D
>> >>> 0BBC620D: D7 F0
>> >>> 0BBC620E: C3 AD
>> >>> 0BBC620F: 7E 0B
>> >>> 0C6A00CC: 12 31
>> >>> 0C6A00CD: CA 30
>> >>> 0DE24C8C: E7 31
>> >>> 0DE24C8D: 5B 30
>> >>> 0DE24C8E: D2 71
>> >>> 0DE24C8F: 78 68
>> >>> 0E3D05CC: 1B 31
>> >>> 0E3D05CD: D9 30
>> >>> 0E3D05CE: 2E 71
>> >>> 0E3D05CF: 67 68
>> >>> 0FD1244C: 30 31
>> >>> 0FD1244D: DB 30
>> >>>
>> >> There are some patterns which repeat themselves. The sequence 30 31
>> >> hex
>> >> often appear in the adjacent positions xxxxxxxC xxxxxxxD, while 68
>> >> appears
>> >> in
>> >> position xxxxxxxF.
>> >>
>> >> I have 2 Harddisks but it does not matter which is source or
>> >> destination,
>> >> it
>> >> can also coincide. (I first noted it when nero in verification phase
>> >> found
>> >> differences between source and masterized copy)
>> >>
>> >> The errors do not occure when i use DOS copy in Windows started in
>> >> save
>> >> mode!
>> >>
>> >> Therefore I exclude HW problems. (Anyway I already changed IDE cables
>> >> and
>> >> run memtest). Also, updating the driver VIA 4in1 did not help.
>> >>
>> >> please, help!
>> >
>> > Not sure whether the D: drive you indicate is local or network.
>> >
>> > I had problems of a similar nature about 12 years ago with Netware
>> > "lite,"
>> > which would randomly change bytes in large copied files. The
>> > destination
>> > file would occasionally have bytes changed - always in the same files,
>> > same
>> > byte-offset, and the changed-to pattern was always one of a small set
>> > of
>> > rogue bytes.
>> >
>> > As far as I'm aware, since Novell hasn't got back to me about it as
>> > promised, they're still working on it....
>> >
>> > Is there anything of this nature in your setup?
>> >
>> > HTH
>> >
>> > ...Bill
>> >
>> >
>>

Archived from groups: microsoft.public.windowsxp.general (More info?)

"Berni" <Berni@discussions.microsoft.com> wrote in message
news:99B7A563-FFE5-4E99-A82F-8E97F55FAC5B@microsoft.com...
>
>
> "David Candy" wrote:
>
>> This is a problem, while rare, that is usually caused by network card
>> drivers. Maybe Novell drivers were like Windows drivers.
>
> No sorry, it is disk to disk, it happens even when creating a copy on the
> same drive - any idea?
>

Check your ram www.memtest.org Make sure you have the latest chipset drivers
for your motherboard. Is one particular hard drive always involved in the
copy? Is the computer overclocked? I have even seen a bad power supply cause
this problem. It can be tough to find.

Kerry

Archived from groups: microsoft.public.windowsxp.general (More info?)

Sorry for post this one 3 times - I am using the web interface and had some
difficulties finding my posts. Will not happen again.

"Pegasus (MVP)" wrote:

>
> "Berni" <Berni@discussions.microsoft.com> wrote in message
> news:CD7445ED-5FF4-431D-828A-AECB2DF99BE6@microsoft.com...
> > I have a problem when copying large files (50MB+):
> > Both the DOS copy /B and the drag/drop or copy/paste methods in explorer
> > result always in a slightly different (corrupt) copy without generating
> any
> > error message. Aparently everything is fine but when checking on binary
> > level, there are differences. Depending on the application this result in
> > unreadble files.
> > The number of changed bytes is proportional to the length of the file.
> >
> > Example: when I copy a file of about 300MB it results in a compare as
> follows:
> > > D:\>fc /B aa.ape bb.ape
> > > Comparing file aa.ape and BB.APE
> > > 0054204C: 7F 31
> > > 0054204D: D8 30
> > > 03DD478E: B8 F8
> > > 0B16184E: 7F AD
> > > 0B16184F: C4 0B
> > > 0BBC620C: CA 0D
> > > 0BBC620D: D7 F0
> > > 0BBC620E: C3 AD
> > > 0BBC620F: 7E 0B
> > > 0C6A00CC: 12 31
> > > 0C6A00CD: CA 30
> > > 0DE24C8C: E7 31
> > > 0DE24C8D: 5B 30
> > > 0DE24C8E: D2 71
> > > 0DE24C8F: 78 68
> > > 0E3D05CC: 1B 31
> > > 0E3D05CD: D9 30
> > > 0E3D05CE: 2E 71
> > > 0E3D05CF: 67 68
> > > 0FD1244C: 30 31
> > > 0FD1244D: DB 30
> > >
> > There are some patterns which repeat themselves. The sequence 30 31 hex
> > often appear in the adjacent positions xxxxxxxC xxxxxxxD, while 68 appears
> in
> > position xxxxxxxF.
> >
> > I have 2 Harddisks but it does not matter which is source or destination,
> it
> > can also coincide. (I first noted it when nero in verification phase found
> > differences between source and masterized copy)
> >
> > The errors do not occure when i use DOS copy in Windows started in save
> mode!
> >
> > Therefore I exclude HW problems. (Anyway I already changed IDE cables and
> > run memtest). Also, updating the driver VIA 4in1 did not help.
> >
> > please, help!
>
> I suggest you run the following batch file from a Command Prompt:
>
> @echo off
> xcopy /v /b "SourceFolder\SourceFile" "DestFolder\DestFile"
> echo Errorlevel for xcopy was %ErrorLevel%
> pause
> fc /b "SourceFolder\SourceFile" "DestFolder\DestFile" | more
> pause

I tried this(without /v /b which were not recognized switches), but the
result is exactly the same: no error and corrupt copy, same result as normal
copy.


>
> xxcopy /v /b "SourceFolder\SourceFile" "DestFolder\DestFile"
> echo Errorlevel for xxcopy was %ErrorLevel%
> pause
> fc /b "SourceFolder\SourceFile" "DestFolder\DestFile" | more

idem (v/ b/ not recognized, second parameter must be directory): errorcode 0
and corrupt copy.

>
> While this might not solve your problem, it could shed some
> light on your problem. xxcopy.exe is downloadable from various
> sites.
>

I hope that the fact these tools aslo fail will lead you to some conclusion.

Archived from groups: microsoft.public.windowsxp.general (More info?)

"R. McCarty" wrote:

> Go to Device Manager, Disk Drives category, Double-Click your drive
> From the details box click the Policies (TAB). Uncheck "Enable Write
> Cache", Apply & then reboot and retry your copy operations.

I tried it, the copy runs now much slower (110 sec against 40 sec with cache).
The output file is still corrupt, seems in less positions: I made 4 tests
and with cache I got 20, 32, 14, 15 differences while without cache I got 8,
22, 5, 6. So even if this sample is not very significative - the average is
around the half.


> Also,
> could you post which Vendor/Model (& Interface type) drive you're
> having issues with.
>

I have 2 Maxtor disks, one 60 and one 200 MB (new). Both behave the same!
Both attached to same IDE channel.
>
>
> "Berni" <Berni@discussions.microsoft.com> wrote in message
> news:99B7A563-FFE5-4E99-A82F-8E97F55FAC5B@microsoft.com...
> >
> >
> > "David Candy" wrote:
> >
> >> This is a problem, while rare, that is usually caused by network card
> >> drivers. Maybe Novell drivers were like Windows drivers.
> >
> > No sorry, it is disk to disk, it happens even when creating a copy on the
> > same drive - any idea?
> >
> >>
> >> --
> >> --------------------------------------------------------------------------------------------------
> >> http://webdiary.smh.com.au/archive [...] 01075.html
> >> =================================================
> >> "billious" <billious_1954@hotmail.com> wrote in message
> >> news:432613e3$0$12704$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> >> >
> >> > "Berni" <Berni@discussions.microsoft.com> wrote in message
> >> > news:CD7445ED-5FF4-431D-828A-AECB2DF99BE6@microsoft.com...
> >> >>I have a problem when copying large files (50MB+):
> >> >> Both the DOS copy /B and the drag/drop or copy/paste methods in
> >> >> explorer
> >> >> result always in a slightly different (corrupt) copy without
> >> >> generating
> >> >> any
> >> >> error message. Aparently everything is fine but when checking on
> >> >> binary
> >> >> level, there are differences. Depending on the application this result
> >> >> in
> >> >> unreadble files.
> >> >> The number of changed bytes is proportional to the length of the file.
> >> >>
> >> >> Example: when I copy a file of about 300MB it results in a compare as
> >> >> follows:
> >> >>> D:\>fc /B aa.ape bb.ape
> >> >>> Comparing file aa.ape and BB.APE
> >> >>> 0054204C: 7F 31
> >> >>> 0054204D: D8 30
> >> >>> 03DD478E: B8 F8
> >> >>> 0B16184E: 7F AD
> >> >>> 0B16184F: C4 0B
> >> >>> 0BBC620C: CA 0D
> >> >>> 0BBC620D: D7 F0
> >> >>> 0BBC620E: C3 AD
> >> >>> 0BBC620F: 7E 0B
> >> >>> 0C6A00CC: 12 31
> >> >>> 0C6A00CD: CA 30
> >> >>> 0DE24C8C: E7 31
> >> >>> 0DE24C8D: 5B 30
> >> >>> 0DE24C8E: D2 71
> >> >>> 0DE24C8F: 78 68
> >> >>> 0E3D05CC: 1B 31
> >> >>> 0E3D05CD: D9 30
> >> >>> 0E3D05CE: 2E 71
> >> >>> 0E3D05CF: 67 68
> >> >>> 0FD1244C: 30 31
> >> >>> 0FD1244D: DB 30
> >> >>>
> >> >> There are some patterns which repeat themselves. The sequence 30 31
> >> >> hex
> >> >> often appear in the adjacent positions xxxxxxxC xxxxxxxD, while 68
> >> >> appears
> >> >> in
> >> >> position xxxxxxxF.
> >> >>
> >> >> I have 2 Harddisks but it does not matter which is source or
> >> >> destination,
> >> >> it
> >> >> can also coincide. (I first noted it when nero in verification phase
> >> >> found
> >> >> differences between source and masterized copy)
> >> >>
> >> >> The errors do not occure when i use DOS copy in Windows started in
> >> >> save
> >> >> mode!
> >> >>
> >> >> Therefore I exclude HW problems. (Anyway I already changed IDE cables
> >> >> and
> >> >> run memtest). Also, updating the driver VIA 4in1 did not help.
> >> >>
> >> >> please, help!
> >> >
> >> > Not sure whether the D: drive you indicate is local or network.
> >> >
> >> > I had problems of a similar nature about 12 years ago with Netware
> >> > "lite,"
> >> > which would randomly change bytes in large copied files. The
> >> > destination
> >> > file would occasionally have bytes changed - always in the same files,
> >> > same
> >> > byte-offset, and the changed-to pattern was always one of a small set
> >> > of
> >> > rogue bytes.
> >> >
> >> > As far as I'm aware, since Novell hasn't got back to me about it as
> >> > promised, they're still working on it....
> >> >
> >> > Is there anything of this nature in your setup?
> >> >
> >> > HTH
> >> >
> >> > ...Bill
> >> >
> >> >
> >>
>
>
>

Archived from groups: microsoft.public.windowsxp.general (More info?)

"Kerry Brown" wrote:

> "Berni" <Berni@discussions.microsoft.com> wrote in message
> news:99B7A563-FFE5-4E99-A82F-8E97F55FAC5B@microsoft.com...
> >
> >
> > "David Candy" wrote:
> >
> >> This is a problem, while rare, that is usually caused by network card
> >> drivers. Maybe Novell drivers were like Windows drivers.
> >
> > No sorry, it is disk to disk, it happens even when creating a copy on the
> > same drive - any idea?
> >
>
> Check your ram www.memtest.org

Done, see initial post

> Make sure you have the latest chipset drivers
> for your motherboard.

Done, see initial post

> Is one particular hard drive always involved in the
> copy?

Source is one of my 2 HD, 60MB and 200MB Maxtor, both on same IDE channel.
Cable checked.

> Is the computer overclocked?

How can I check this?

> I have even seen a bad power supply cause
> this problem.

How can I chewck this?

> It can be tough to find.
>
Don't encourage me so much

Thanks all for your interest!
Berni

> Kerry
>
>
>