large file copy results in corrupted copies

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!
16 answers Last reply
More about large file copy results corrupted copies
  1. 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.
  2. 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/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=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/scriptcenter/default.mspx
  3. 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
  4. 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/archives/_comment/001075.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
    >
    >
  5. 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/archives/_comment/001075.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
    > >
    > >
    >
  6. 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
  7. 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.
  8. 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
    >
    >
    >
  9. Archived from groups: microsoft.public.windowsxp.general (More info?)

    "Berni" <Berni@discussions.microsoft.com> wrote in message
    news:2BEC704D-DD29-4463-9B83-24D4F4DD3449@microsoft.com...
    >
    >
    > "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!

    Sorry, if I was repeating what you've already done. How long did you let
    memtest run? Which memtest program did you use? I would try R. McCarty's
    suggestion of trying the drives on a different channel. It does sound more
    and more like a motherboard/controller problem. You can measure voltages on
    a power supply but the easiest way to test is to swap in a known good one.
    Unless you have a very accurate meter and test under a load the voltages
    don't tell you much. The only sure way to tell if your system is overclocked
    is to physically identify the CPU and make sure it is running at the right
    frequency. If you didn't overclock the system in all likelihood it is not
    overclocked.

    Kerry
  10. 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/archives/_comment/001075.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
    >> >
    >> >
    >>
  11. 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/archives/_comment/001075.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
    > >> >
    > >> >
    > >>
    >
    >
    >
  12. Archived from groups: microsoft.public.windowsxp.general (More info?)

    Thanks for testing and the results. If you're still inclined to test more
    I would switch your IDE Primary and Secondary connectors on the
    motherboard (Test using the other Channel). You should also reset
    the Write cache on both drives. I would carefully check the BIOS
    settings for the IDE channels and while in Windows check settings
    on the Primary, Secondary and make sure the drives are running at
    UDMA Mode 5 or 6. This seems to be a motherboard issue, not a
    drive related one. If they are new drives, you might consider getting
    a SATA controller card and two IDE-to-SATA conversion adapters.
    On machines that don't have SATA but new large/fast drives I've
    starting configuring them that way, so each has it's own dedicated
    channel to work from. A SATA card is fairly cheap at ~$30.00 &
    the conversion modules are even less at around ~$17.00. Anyway,
    this seems like a motherboard or chipset issue.

    "Berni" <Berni@discussions.microsoft.com> wrote in message
    news:35A43E2A-1DC7-465D-AECB-DA5A9EA67BFF@microsoft.com...
    >
    >
    > "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/archives/_comment/001075.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
    >> >> >
    >> >> >
    >> >>
    >>
    >>
    >>
  13. Archived from groups: microsoft.public.windowsxp.general (More info?)

    Thanks to all who try to help me out!

    I will try the IDE channel test when I'm home this evening ...
    Just one doubt: How can it be a HW problem, when the copy works perfectly in
    case I start windows in temporary/save mode. I thought that winXP drives the
    HW somewhat different?

    Kerry: I used memtest86, at least one full turn around through all steps. If
    I remember well it lasted about 15 minutes. The copy problem occures always!

    Cheers
    Berni

    "R. McCarty" wrote:

    > Thanks for testing and the results. If you're still inclined to test more
    > I would switch your IDE Primary and Secondary connectors on the
    > motherboard (Test using the other Channel). You should also reset
    > the Write cache on both drives. I would carefully check the BIOS
    > settings for the IDE channels and while in Windows check settings
    > on the Primary, Secondary and make sure the drives are running at
    > UDMA Mode 5 or 6. This seems to be a motherboard issue, not a
    > drive related one. If they are new drives, you might consider getting
    > a SATA controller card and two IDE-to-SATA conversion adapters.
    > On machines that don't have SATA but new large/fast drives I've
    > starting configuring them that way, so each has it's own dedicated
    > channel to work from. A SATA card is fairly cheap at ~$30.00 &
    > the conversion modules are even less at around ~$17.00. Anyway,
    > this seems like a motherboard or chipset issue.
    >
    > "Berni" <Berni@discussions.microsoft.com> wrote in message
    > news:35A43E2A-1DC7-465D-AECB-DA5A9EA67BFF@microsoft.com...
    > >
    > >
    > > "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/archives/_comment/001075.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
    > >> >> >
    > >> >> >
    > >> >>
    > >>
    > >>
    > >>
    >
    >
    >
  14. Archived from groups: microsoft.public.windowsxp.general (More info?)

    "Berni" <Berni@discussions.microsoft.com> wrote in message
    news:2BC2984D-3933-4982-BDEE-734696152F73@microsoft.com...
    > Thanks to all who try to help me out!
    >
    > I will try the IDE channel test when I'm home this evening ...
    > Just one doubt: How can it be a HW problem, when the copy works perfectly
    > in
    > case I start windows in temporary/save mode. I thought that winXP drives
    > the
    > HW somewhat different?
    >
    > Kerry: I used memtest86, at least one full turn around through all steps.
    > If
    > I remember well it lasted about 15 minutes. The copy problem occures
    > always!
    >

    You should let memtest86 run for several hours at least. It probably isn't
    the problem but that possible cause should be eliminated. Windows XP demands
    a lot more from the hardware than DOS or safe mode. In safe mode the hard
    drives are accessed much differently than regular mode.

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

    "Kerry Brown" wrote:

    > "Berni" <Berni@discussions.microsoft.com> wrote in message
    > news:2BC2984D-3933-4982-BDEE-734696152F73@microsoft.com...
    > > Thanks to all who try to help me out!
    > >
    > > I will try the IDE channel test when I'm home this evening ...
    > > Just one doubt: How can it be a HW problem, when the copy works perfectly
    > > in
    > > case I start windows in temporary/save mode. I thought that winXP drives
    > > the
    > > HW somewhat different?
    > >
    > > Kerry: I used memtest86, at least one full turn around through all steps.
    > > If
    > > I remember well it lasted about 15 minutes. The copy problem occures
    > > always!
    > >
    >
    > You should let memtest86 run for several hours at least. It probably isn't
    > the problem but that possible cause should be eliminated. Windows XP demands
    > a lot more from the hardware than DOS or safe mode. In safe mode the hard
    > drives are accessed much differently than regular mode.
    >
    > Kerry
    >
    >
    >
    Hi guys, thanks a lot for your help.
    After executing the tests that R. McCarty and Kerry suggested I conclude
    that it must be HW (motherboard, chipset) - I will carry my PC to a service
    shop and I will see if I go for the PCI SATA Controller + adapters or for a
    new motherboard ...
    I will post if they find another reason -
    thanks again
    Berni
  16. Archived from groups: microsoft.public.windowsxp.general (More info?)

    "Berni" <Berni@discussions.microsoft.com> wrote in message
    news:667543C8-CBE1-4E97-A46B-AE61249B9463@microsoft.com...
    >
    >
    > "Kerry Brown" wrote:
    >
    >> "Berni" <Berni@discussions.microsoft.com> wrote in message
    >> news:2BC2984D-3933-4982-BDEE-734696152F73@microsoft.com...
    >> > Thanks to all who try to help me out!
    >> >
    >> > I will try the IDE channel test when I'm home this evening ...
    >> > Just one doubt: How can it be a HW problem, when the copy works
    >> > perfectly
    >> > in
    >> > case I start windows in temporary/save mode. I thought that winXP
    >> > drives
    >> > the
    >> > HW somewhat different?
    >> >
    >> > Kerry: I used memtest86, at least one full turn around through all
    >> > steps.
    >> > If
    >> > I remember well it lasted about 15 minutes. The copy problem occures
    >> > always!
    >> >
    >>
    >> You should let memtest86 run for several hours at least. It probably
    >> isn't
    >> the problem but that possible cause should be eliminated. Windows XP
    >> demands
    >> a lot more from the hardware than DOS or safe mode. In safe mode the hard
    >> drives are accessed much differently than regular mode.
    >>
    >> Kerry
    >>
    >>
    >>
    > Hi guys, thanks a lot for your help.
    > After executing the tests that R. McCarty and Kerry suggested I conclude
    > that it must be HW (motherboard, chipset) - I will carry my PC to a
    > service
    > shop and I will see if I go for the PCI SATA Controller + adapters or for
    > a
    > new motherboard ...
    > I will post if they find another reason -
    > thanks again

    Thanks for the update. Let us know what they find.

    Kerry
Ask a new question

Read More

Windows XP