Last night I detached a 110 Gig 2000 database on Win 2000
system and was copying it from a slow SAN drive to a
faster SAN drive. Three times in a row I observed the
same behavior:
--Windows Explorer would show the file being copied for
about ten minutes.
--After ten minutes Windows Explorer would vaporize, i.e.
disappear completely.
--Then on the new SAN drive I noticed that a 110 Gig file
was left there, i.e. Windows Explorer was not even able
to erase the failed copy.
Has anyone ever seen something like this before? Any
ideas what could cause this? (There was nothing in the
Event/App Viewer.)
Hi
Try to use command line XCOPY. Explorer does have a few quirks and is
generally slower on such big files.
Regards
Mike
"Blk" wrote:
> Last night I detached a 110 Gig 2000 database on Win 2000
> system and was copying it from a slow SAN drive to a
> faster SAN drive. Three times in a row I observed the
> same behavior:
> --Windows Explorer would show the file being copied for
> about ten minutes.
> --After ten minutes Windows Explorer would vaporize, i.e.
> disappear completely.
> --Then on the new SAN drive I noticed that a 110 Gig file
> was left there, i.e. Windows Explorer was not even able
> to erase the failed copy.
> Has anyone ever seen something like this before? Any
> ideas what could cause this? (There was nothing in the
> Event/App Viewer.)
>
|||"Blk" <anonymous@.discussions.microsoft.com> schrieb im Newsbeitrag
news:175b01c50ad3$b48046d0$a401280a@.phx.gbl...
> Last night I detached a 110 Gig 2000 database on Win 2000
> system and was copying it from a slow SAN drive to a
> faster SAN drive. Three times in a row I observed the
> same behavior:
> --Windows Explorer would show the file being copied for
> about ten minutes.
> --After ten minutes Windows Explorer would vaporize, i.e.
> disappear completely.
> --Then on the new SAN drive I noticed that a 110 Gig file
> was left there, i.e. Windows Explorer was not even able
> to erase the failed copy.
> Has anyone ever seen something like this before? Any
> ideas what could cause this? (There was nothing in the
> Event/App Viewer.)
The OS was probably still writing the file. You can either wait or use a
tool like process explorer (sysinternals) to check which process has a
handle on that file.
Kind regards
robert
|||Does XCOPY give you status on a large file?
>--Original Message--
>Hi
>Try to use command line XCOPY. Explorer does have a few
quirks and is[vbcol=seagreen]
>generally slower on such big files.
>Regards
>Mike
>"Blk" wrote:
2000[vbcol=seagreen]
for[vbcol=seagreen]
i.e.[vbcol=seagreen]
file[vbcol=seagreen]
able[vbcol=seagreen]
the
>.
>
|||I don't think so, because I was able to delete the file,
i.e. there were no locks on it.
>--Original Message--
>"Blk" <anonymous@.discussions.microsoft.com> schrieb im
Newsbeitrag[vbcol=seagreen]
>news:175b01c50ad3$b48046d0$a401280a@.phx.gbl...
2000[vbcol=seagreen]
i.e.[vbcol=seagreen]
file
>The OS was probably still writing the file. You can
either wait or use a
>tool like process explorer (sysinternals) to check which
process has a
>handle on that file.
>Kind regards
> robert
>.
>
|||"Blk" <anonymous@.discussions.microsoft.com> wrote in message
news:070401c50ada$e88c3c20$a501280a@.phx.gbl...
> Does XCOPY give you status on a large file?
No, but find the resource kit for 2K and get a copy of robocopy.exe.
excellent tool.
[vbcol=seagreen]
>
> quirks and is
> 2000
> for
> i.e.
> file
> able
> the
No comments:
Post a Comment