xcopy /z and resuming - and the no percentage

[jameshanley39@yahoo.co.uk]

I know that copy /z gives a percentage.

But it seems that xcopy doesn't. Fair enough. But i'd like to know how
far it has got.

Suppose I break and resume (I know, prob only possible to resume for a
network copy, but ok, let's say it's a network copy)

Are there any ways - even very techie ways - to show how much has
been copied e.g. how many bytes.

and so when see that it resumed, ..that it has added to those bytes.

so that if one pauses it, and then resumes, one can see.

Maybe a program that can quickly browse through bytes of a 200MB
file ?

note- I know that copy and suspect xcopy too, only resumes for network
copies, like (or i.e. rather) copying to a mapped network drive. So I
am referring to that.

 

[jameshanley39@yahoo.co.uk]

xcopy /z does nothing ! (win xp sp2)

On Jul 4, 6:26 am, "jameshanle...@yahoo.co.uk"
<jameshanle...@yahoo.co.uk> wrote:
> I know that copy /z gives a percentage.
>
> But it seems thatxcopydoesn't. Fair enough. But i'd like to know how
> far it has got.
>
> Suppose I break andresume(I know, prob only possible toresumefor a
> network copy, but ok, let's say it's a network copy)
>
> Are there any ways - even very techie ways  - to show how much has
> been copied e.g. how many bytes.
>
> and so when see that it resumed, ..that it has added to those bytes.
>
> so that if one pauses it, and then resumes, one can see.
>
> Maybe a program that can quickly browse through bytes of a 200MB
> file ?
>
> note- I know that copy and suspectxcopytoo, only resumes for network
> copies, like (or i.e. rather)  copying to a mapped network drive. So I
> am referring to that.

ok..
I have found xvi32 is a good program for viewing/editting (small or)
large binary files.

But here is a big problem.

xcopy with the /z switch has absolutely no effect at all.

copy /z does.

If you do xcopy with /z , with dest/target file on a network
drive(mapped drive), and ctrl-c , then windows deletes the target
file. Whereas with copy /z, (to a netowrk drive, and doing ctrl-c)
the file remains.

xcopy /z is doing absolutely nothing.

 

[John John (MVP)]

/Z Copies networked files in restartable mode.

If Xcopy doesn't do what you want then you will have to find another
utility to fill your needs. There isn't much we can do about what xcopy
does or doesn't do by design.

John


xcopy /?

Copies files and directory trees.

XCOPY source [destination] [/A | /M] [/D[:date]] [/P] [/S [/E]] [/V] [/W]
[/C] [/I] [/Q] [/F] [/L] [/H] [/R] [/T] [/U]
[/K] [/N] [/Z]

source Specifies the file(s) to copy.
destination Specifies the location and/or name of new files.
/A Copies files with the archive attribute set,
doesn't change the attribute.
/M Copies files with the archive attribute set,
turns off the archive attribute.
/D:m-d-y Copies files changed on or after the specified date.
If no date is given, copies only those files whose
source time is newer than the destination time.
/P Prompts you before creating each destination file.
/S Copies directories and subdirectories except empty ones.
/E Copies directories and subdirectories, including empty ones.
Same as /S /E. May be used to modify /T.
/V Verifies each new file.
/W Prompts you to press a key before copying.
/C Continues copying even if errors occur.
/I If destination does not exist and copying more than one
file,
assumes that destination must be a directory.
/Q Does not display file names while copying.
/F Displays full source and destination file names while
copying.
/L Displays files that would be copied.
/H Copies hidden and system files also.
/R Overwrites read-only files.
/T Creates directory structure, but does not copy files.
Does not
include empty directories or subdirectories. /T /E includes
empty directories and subdirectories.
/U Copies only files that already exist in destination.
/K Copies attributes. Normal Xcopy will reset read-only
attributes.
/N Copies using the generated short names.
/Z Copies networked files in restartable mode.


jameshanley39@yahoo.co.uk wrote:
> I know that copy /z gives a percentage.
>
> But it seems that xcopy doesn't. Fair enough. But i'd like to know how
> far it has got.
>
> Suppose I break and resume (I know, prob only possible to resume for a
> network copy, but ok, let's say it's a network copy)
>
> Are there any ways - even very techie ways - to show how much has
> been copied e.g. how many bytes.
>
> and so when see that it resumed, ..that it has added to those bytes.
>
> so that if one pauses it, and then resumes, one can see.
>
> Maybe a program that can quickly browse through bytes of a 200MB
> file ?
>
> note- I know that copy and suspect xcopy too, only resumes for network
> copies, like (or i.e. rather) copying to a mapped network drive. So I
> am referring to that.

 

[jameshanley39@yahoo.co.uk]

Re: xcopy /z and resuming - and the no percentage

On Jul 4, 12:17 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
> /Z  Copies networked files in restartable mode.
>
> If Xcopy doesn't do what you want then you will have to find another
> utility to fill your needs.  There isn't much we can do about what xcopy
> does or doesn't do by design.
>
> John
>
> xcopy /?

that is precisely what I didn't need.

I know what /z does, since I have used it with COPY.

Can you demonstrate /Z working?

If I xcopy /z a file to a mapped network drive, and do ctrl-c the
destination file disappears.

That is not going to restart . I tested it too.

Does this problem happen on your machine?

The only way you would know, is from copying a big file, like a 200MB
file, and then stopping it. And then copying it again.

Does xcopy delete the destination file as soon as the copy is
interrupted? That certainly prevents a resumption.

Do you see this behaviour too.

Remember, read my claim properly.

I said /z DOES ABSOLUTELY NOTHING. Meaning it doesn't do what it says
on the tin.

 

[jameshanley39@yahoo.co.uk]

Re: xcopy /z and resuming - and the no percentage

On Jul 4, 4:27 pm, "jameshanle...@yahoo.co.uk"
<jameshanle...@yahoo.co.uk> wrote:
> On Jul 4, 12:17 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
>
> > /Z  Copies networked files in restartable mode.
>
> > If Xcopy doesn't do what you want then you will have to find another
> > utility to fill your needs.  There isn't much we can do about what xcopy
> > does or doesn't do by design.
>
> > John
>
> > xcopy /?
>
> that is precisely what I didn't need.
>
> I know what /z does, since I have used it with COPY.
>
> Can you demonstrate /Z working?
>
> If I xcopy /z a file to a mapped network drive, and do ctrl-c   the
> destination file disappears.
>
> That is not going to restart . I tested it too.
>
> Does this problem happen on your machine?
>
> The only way you would know, is from copying a big file, like a 200MB
> file, and then stopping it. And then copying it again.
>
> Does xcopy delete the destination file as soon as the copy is
> interrupted? That certainly prevents a resumption.
>
> Do you see this behaviour too.
>
> Remember, read my claim properly.
>
> I said /z DOES ABSOLUTELY NOTHING. Meaning it doesn't do what it says
> on the tin.

ok.. I see what it was now.

I was familiar with copy /z , and had tested that, and with that,
pulling out a network cable had the same effect as doing ctrl-c

With xcopy /z this is not the case. ctrl-c removes the file.

But if the xcopy /z is stopped by a network problem (the one I tested
- pulling out the cable) then it does resume.

I can really see the resumption with xvi32. (finding the end of its
writing by searching up from the bottom for a non zero character )
Doing a copy where I leave it for a short while, (leaves a file of
like 100MB) then doing a small copy. And seeing if the file is small
like 9MB or over 100MB.
I haven't tried opening it during and refreshing it, maybe some progs
can do that, that would bea bit interesting!

With copy /z you got a % too.. so I didn't use xvi32 to test for
resumptions.
after resuming the % started where it left off.

 

[jameshanley39@yahoo.co.uk]

Re: xcopy /z and resuming - and the no percentage

On Jul 4, 5:43 pm, "jameshanle...@yahoo.co.uk"
<jameshanle...@yahoo.co.uk> wrote:
> On Jul 4, 4:27 pm, "jameshanle...@yahoo.co.uk"
>
<snip>

and btw john, since you mentioned /?

notice that they have exactly the same description for /Z, and it
doesn't mention details.

C:\Documents and Settings\name>copy /? | find /i "/z"
COPY [/D] [/V] [/N] [/Y | /-Y] [/Z] [/A | /B ] source [/A | /B]
/Z Copies networked files in restartable mode.

C:\Documents and Settings\name>xcopy /? | find /i "/z"
[/K] [/N] [/O] [/X] [/Y] [/-Y] [/Z]
/Z Copies networked files in restartable mode.

 

[John John (MVP)]

Re: xcopy /z and resuming - and the no percentage

jameshanley39@yahoo.co.uk wrote:

> On Jul 4, 12:17 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
>
>>/Z Copies networked files in restartable mode.
>>
>>If Xcopy doesn't do what you want then you will have to find another
>>utility to fill your needs. There isn't much we can do about what xcopy
>>does or doesn't do by design.
>>
>>John
>>
>>xcopy /?
>
>
> that is precisely what I didn't need.
>
> I know what /z does, since I have used it with COPY.
>
> Can you demonstrate /Z working?
>
> If I xcopy /z a file to a mapped network drive, and do ctrl-c the
> destination file disappears.

That is to be expected, Ctrl-C stops the execution of the command or the
batch script. When you do Ctrl-C you kill Xcopy, how can you then
expect it to resume?

The /Z switch is not meant to restart xcopy if it is killed, it is a
command to xcopy to tell it to retry the copy if it is interrupted by
other problems, like a drop in the network connection, then Xcopy will
retry the connection. If you kill xcopy before it finishes copying the
file then the destination file is incomplete and corrupt and it will not
be saved to the disk in an incomplete and corrupt state.

John

 

[jameshanley39@yahoo.co.uk]

Re: xcopy /z and resuming - and the no percentage

On Jul 4, 6:20 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
> jameshanle...@yahoo.co.uk wrote:
> > On Jul 4, 12:17 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
>
> >>/Z  Copies networked files in restartable mode.
>
> >>IfXcopydoesn't do what you want then you will have to find another
> >>utility to fill your needs.  There isn't much we can do about whatxcopy
> >>does or doesn't do by design.
>
> >>John
>
> >>xcopy/?
>
> > that is precisely what I didn't need.
>
> > I know what /z does, since I have used it with COPY.
>
> > Can you demonstrate /Z working?
>
> > If Ixcopy/z a file to a mapped network drive, and do ctrl-c   the
> > destination file disappears.
>
> That is to be expected, Ctrl-C stops the execution of the command or the
> batch script.  When you do Ctrl-C you killXcopy, how can you then
> expect it to resume?
>

With copy /z where src or dest is a network drive, Ctrl-C does not
delete the dest file.
With xcopy, whether /z or not, it does delete it.

I doubt one can explain how that is "Expected" , oter than just
knowing that it behaves like that.

Regarding the "how can I expect it to resume" , see below.


> The /Z switch is not meant to restartxcopyif it is killed, it is a
> command toxcopyto tell it to retry the copy if it is interrupted by
> other problems, like a drop in the network connection, thenXcopywill
> retry the connection.  

That is not correct..
Firstly, I wouldn't have expected that to be the case
Secondly, according to my tests, that is not the case.


Even without /Z
if you pull the cable out
(e.g. at the router 'cos if you do it at the computer end, you get a
popup, and windows starts thinking)
I pulled the cat5 cable from the router.
For 3 seconds. Then put it back in.

The copy continued fine.

That was even without /Z

And that is to be expected.
Remember, the copy is going fine and being converted into packets. And
then packets are being lost.
TCP/IP is designed to deal with that.
The receiving computer can request packets it missed, and it
reassembles them in correct order. And would see if a packet needs to
be resent.

If you actually tested /Z properly, then you'd have seen that what yo
thought its function is, occurs even without it.

Its function is as I said. But I will be a bit clearer.

Say you do a copy with /Z, (where src or dst involves a network drive)
and the copy is interrupted in a certain way whereby it can be resumed
e.g. cable pulled out.
Then, when I say it can be resumed.
I mean that if you then do copy AGAIN (with /Z again)
it will ask if you want to overwrite the file, say Yes. But it will
actually continue writing the file from where it left off. .

> If you killxcopybefore it finishes copying the
> file then the destination file is incomplete and corrupt and it will not
> be saved to the disk in an incomplete and corrupt state.
>

Not true.

If you had tested it, you'd know that was not true.

The fc command would test the original file with the copied file, and
prove that wasn't the case. That the dest file was not corrupted.
And this is even without the /Z



NOTE-
it seems to me , from my tests, that if you want to resume..

With COPY,
there are a few variables.
/Z or not
whether src or dest refers to a Network drive or not
is it interrupted with ctrl-c? closing the cmd window? cable pulled
out for a while?

The way COPY works, is when you start the copy, it creates the file of
full size on the dest . Then it fills it in with the correct byte
values. I guess this ensures you don't get a suprise about
insufficient space during the middle of writing the file. It is
created full size right at the start, from 0 to full size.

That dest file is a condition for a resumption to be possible.
I think another condition is it stops with the error
If you do a copy without any network drive referred to, and you do a
ctrl-c, it will delete the dest file. No resumption possible.
If you do a copy and close the window, and no network drive referred
to, then the dest file remains there. But it will not resume.

There has to be a network drive in src or dest for the resumption to
work.
then a ctrl-c won't delete the file.
resumption is possible after a close command prompt window, or ctrl-c

Both copies have to be done /Z, the first one that failed with an
error.
And the second one.
There could be more.. All must have /Z

Xcopy, from what I recall..
when done with /Z unfortunately doesn't give a % complete, which is a
nuisance.

whether network drive referred to or not, if you interrupt with ctrl-
c, or close window, it deletes the dest file. so no resumption
possible.

by removing the network cable, causing an error and the copy to hault.
That is a situation where it can resume. (when you do the next xcopy).

presumably like with copy, both xcopies have to be done with /Z

the /Z is of course on an individual file only . So if you copy a list
of files, it won't remember where it was in that.

Some of these details and differences of /Z with copy compared to
xcopy, are probably a bit extreme.. Just quirks really. But main thing
is that
a)resumption that /Z offers is in the sense of a copy being
interrupted in a certain way (which is really intended to be a network
problem like cable removed - and for long enough for the copy or xcopy
command to break out back to the command prompt). And the resumption
occurs with the next copy or xcopy command, also /X

(one can put aside the details about ctrl-c or closing the command
window. They are really quirks, in that it behaves different with copy
and xcopy. And the fact that the resumption only works with network
copies, implies that really MS only had in mind network problems
causing copy or xcopy to stop).

b)it only works when a network drive is in src or dest.

c)know that copy or xcopy creates a file of size 0 which immediately
grows to full size file and is then filled with correct bytes. It's
good to know how things are working. Of course if that file is not
there then it cannot possibly be resumed. And one can see how a second
copy has resumed it, by looking at the file in xvi32.exe

I may have made some errors here. These tests were a rather fiddly and
slightly painstaking business.

 

[jameshanley39@yahoo.co.uk]

Re: xcopy /z and resuming - and the no percentage

On Jul 4, 6:20 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
> jameshanle...@yahoo.co.uk wrote:
> > On Jul 4, 12:17 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
>
> >>/Z Copies networked files in restartable mode.
>
> >>IfXcopydoesn't do what you want then you will have to find another
> >>utility to fill your needs. There isn't much we can do about whatxcopy
> >>does or doesn't do by design.
>
> >>John
>
> >>xcopy/?
>
> > that is precisely what I didn't need.
>
> > I know what /z does, since I have used it with COPY.
>
> > Can you demonstrate /Z working?
>
> > If Ixcopy/z a file to a mapped network drive, and do ctrl-c the
> > destination file disappears.
>
> That is to be expected, Ctrl-C stops the execution of the command or the
> batch script. When you do Ctrl-C you killXcopy, how can you then
> expect it to resume?
>

With copy /z where src or dest is a network drive, Ctrl-C does not
delete the dest file.
With xcopy, whether /z or not, it does delete it.

I doubt one can explain how that is "Expected" , oter than just
knowing that it behaves like that.

Regarding the "how can I expect it to resume" , see below.


> The /Z switch is not meant to restartxcopyif it is killed, it is a
> command toxcopyto tell it to retry the copy if it is interrupted by
> other problems, like a drop in the network connection, thenXcopywill
> retry the connection.

That is not correct..
Firstly, I wouldn't have expected that to be the case
Secondly, according to my tests, that is not the case.


Even without /Z
if you pull the cable out
(e.g. at the router 'cos if you do it at the computer end, you get a
popup, and windows starts thinking)
I pulled the cat5 cable from the router.
For 3 seconds. Then put it back in.

The copy continued fine.

That was even without /Z

And that is to be expected.
Remember, the copy is going fine and being converted into packets. And
then packets are being lost.
TCP/IP is designed to deal with that.
The receiving computer can request packets it missed, and it
reassembles them in correct order. And would see if a packet needs to
be resent.

If you actually tested /Z properly, then you'd have seen that what yo
thought its function is, occurs even without it.

Its function is as I said. But I will be a bit clearer.

Say you do a copy with /Z, (where src or dst involves a network drive)
and the copy is interrupted in a certain way whereby it can be resumed
e.g. cable pulled out.
Then, when I say it can be resumed.
I mean that if you then do copy AGAIN (with /Z again)
it will ask if you want to overwrite the file, say Yes. But it will
actually continue writing the file from where it left off. .

> If you killxcopybefore it finishes copying the
> file then the destination file is incomplete and corrupt and it will not
> be saved to the disk in an incomplete and corrupt state.
>

Not true.

If you had tested it, you'd know that was not true.

The fc command would test the original file with the copied file, and
prove that wasn't the case. That the dest file was not corrupted.
And this is even without the /Z



NOTE-
it seems to me , from my tests, that if you want to resume..

With COPY,
there are a few variables.
/Z or not
whether src or dest refers to a Network drive or not
is it interrupted with ctrl-c? closing the cmd window? cable pulled
out for a while?

The way COPY works, is when you start the copy, it creates the file of
full size on the dest . Then it fills it in with the correct byte
values. I guess this ensures you don't get a suprise about
insufficient space during the middle of writing the file. It is
created full size right at the start, from 0 to full size.

That dest file is a condition for a resumption to be possible.

If you do a copy without any network drive referred to, and you do a
ctrl-c, it will delete the dest file. No resumption possible.
If you do a copy and close the window, and no network drive referred
to, then the dest file remains there. But it will not resume.

There has to be a network drive in src or dest for the resumption to
work.
then a ctrl-c won't delete the file.
resumption is possible after a close command prompt window, or ctrl-c

Both copies have to be done /Z, the first one that failed with an
error.
And the second one.
There could be more.. All must have /Z

Xcopy, from what I recall..
when done with /Z unfortunately doesn't give a % complete, which is a
nuisance.

whether network drive referred to or not, if you interrupt with ctrl-
c, or close window, it deletes the dest file. so no resumption
possible.

by removing the network cable, causing an error and the copy to hault.
That is a situation where it can resume. (when you do the next xcopy).

presumably like with copy, both xcopies have to be done with /Z

the /Z is of course on an individual file only . So if you copy a list
of files, it won't remember where it was in that.

Some of these details and differences of /Z with copy compared to
xcopy, are probably a bit extreme.. Just quirks really. But main thing
is that
a)resumption that /Z offers is in the sense of a copy being
interrupted in a certain way (which is really intended to be a network
problem like cable removed - and for long enough for the copy or xcopy
command to break out back to the command prompt). And the resumption
occurs with the next copy or xcopy command, also /X

(one can put aside the details about ctrl-c or closing the command
window. They are really quirks, in that it behaves different with copy
and xcopy. And the fact that the resumption only works with network
copies, implies that really MS only had in mind network problems
causing copy or xcopy to stop).

b)it only works when a network drive is in src or dest.

c)know that copy or xcopy creates a file of size 0 which immediately
grows to full size file and is then filled with correct bytes. It's
good to know how things are working. Of course if that file is not
there then it cannot possibly be resumed. And one can see how a second
copy has resumed it, by looking at the file in xvi32.exe

I may have made some errors here. These tests were a rather fiddly
painstaking business.

 

[jameshanley39@yahoo.co.uk]

Re: xcopy /z and resuming - and the no percentage

this post may appear a few times. It is identical. I had some trouble
posting it



On Jul 4, 6:20 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
> jameshanle...@yahoo.co.uk wrote:
> > On Jul 4, 12:17 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
>
> >>/Z Copies networked files in restartable mode.
>
> >>IfXcopydoesn't do what you want then you will have to find another
> >>utility to fill your needs. There isn't much we can do about whatxcopy
> >>does or doesn't do by design.
>
> >>John
>
> >>xcopy/?
>
> > that is precisely what I didn't need.
>
> > I know what /z does, since I have used it with COPY.
>
> > Can you demonstrate /Z working?
>
> > If Ixcopy/z a file to a mapped network drive, and do ctrl-c the
> > destination file disappears.
>
> That is to be expected, Ctrl-C stops the execution of the command or the
> batch script. When you do Ctrl-C you killXcopy, how can you then
> expect it to resume?
>

With copy /z where src or dest is a network drive, Ctrl-C does not
delete the dest file.
With xcopy, whether /z or not, it does delete it.

I doubt one can explain how that is "Expected" , oter than just
knowing that it behaves like that.

Regarding the "how can I expect it to resume" , see below.


> The /Z switch is not meant to restartxcopyif it is killed, it is a
> command toxcopyto tell it to retry the copy if it is interrupted by
> other problems, like a drop in the network connection, thenXcopywill
> retry the connection.

That is not correct..
Firstly, I wouldn't have expected that to be the case
Secondly, according to my tests, that is not the case.


Even without /Z
if you pull the cable out
(e.g. at the router 'cos if you do it at the computer end, you get a
popup, and windows starts thinking)
I pulled the cat5 cable from the router.
For 3 seconds. Then put it back in.

The copy continued fine.

That was even without /Z

And that is to be expected.
Remember, the copy is going fine and being converted into packets. And
then packets are being lost.
TCP/IP is designed to deal with that.
The receiving computer can request packets it missed, and it
reassembles them in correct order. And would see if a packet needs to
be resent.

If you actually tested /Z properly, then you'd have seen that what yo
thought its function is, occurs even without it.

Its function is as I said. But I will be a bit clearer.

Say you do a copy with /Z, (where src or dst involves a network drive)
and the copy is interrupted in a certain way whereby it can be resumed
e.g. cable pulled out.
Then, when I say it can be resumed.
I mean that if you then do copy AGAIN (with /Z again)
it will ask if you want to overwrite the file, say Yes. But it will
actually continue writing the file from where it left off. .

> If you killxcopybefore it finishes copying the
> file then the destination file is incomplete and corrupt and it will not
> be saved to the disk in an incomplete and corrupt state.
>

Not true.

If you had tested it, you'd know that was not true.

The fc command would test the original file with the copied file, and
prove that wasn't the case. That the dest file was not corrupted.
And this is even without the /Z



NOTE-
it seems to me , from my tests, that if you want to resume..

With COPY,
there are a few variables.
/Z or not
whether src or dest refers to a Network drive or not
is it interrupted with ctrl-c? closing the cmd window? cable pulled
out for a while?

The way COPY works, is when you start the copy, it creates the file of
full size on the dest . Then it fills it in with the correct byte
values. I guess this ensures you don't get a suprise about
insufficient space during the middle of writing the file. It is
created full size right at the start, from 0 to full size.

That dest file is a condition for a resumption to be possible.

If you do a copy without any network drive referred to, and you do a
ctrl-c, it will delete the dest file. No resumption possible.
If you do a copy and close the window, and no network drive referred
to, then the dest file remains there. But it will not resume.

There has to be a network drive in src or dest for the resumption to
work.
then a ctrl-c won't delete the file.
resumption is possible after a close command prompt window, or ctrl-c

Both copies have to be done /Z, the first one that failed with an
error.
And the second one.
There could be more.. All must have /Z

Xcopy, from what I recall..
when done with /Z unfortunately doesn't give a % complete, which is a
nuisance.

whether network drive referred to or not, if you interrupt with ctrl-
c, or close window, it deletes the dest file. so no resumption
possible.

by removing the network cable, causing an error and the copy to hault.
That is a situation where it can resume. (when you do the next xcopy).

presumably like with copy, both xcopies have to be done with /Z

the /Z is of course on an individual file only . So if you copy a list
of files, it won't remember where it was in that.

Some of these details and differences of /Z with copy compared to
xcopy, are probably a bit extreme.. Just quirks really. But main thing
is that
a)resumption that /Z offers is in the sense of a copy being
interrupted in a certain way (which is really intended to be a network
problem like cable removed - and for long enough for the copy or xcopy
command to break out back to the command prompt). And the resumption
occurs with the next copy or xcopy command, also /X

(one can put aside the details about ctrl-c or closing the command
window. They are really quirks, in that it behaves different with copy
and xcopy. And the fact that the resumption only works with network
copies, implies that really MS only had in mind network problems
causing copy or xcopy to stop).

b)it only works when a network drive is in src or dest.

c)know that copy or xcopy creates a file of size 0 which immediately
grows to full size file and is then filled with correct bytes. It's
good to know how things are working. Of course if that file is not
there then it cannot possibly be resumed. And one can see how a second
copy has resumed it, by looking at the file in xvi32.exe

I may have made some errors here. These tests were a rather fiddly
painstaking business.

 

[John John (MVP)]

Re: xcopy /z and resuming - and the no percentage

jameshanley39@yahoo.co.uk wrote:

>
> On Jul 4, 6:20 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
>
>>jameshanle...@yahoo.co.uk wrote:
>>
>>>On Jul 4, 12:17 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
>>
>>>>/Z Copies networked files in restartable mode.
>>
>>>>IfXcopydoesn't do what you want then you will have to find another
>>>>utility to fill your needs. There isn't much we can do about whatxcopy
>>>>does or doesn't do by design.
>>
>>>>John
>>
>>>>xcopy/?
>>
>>>that is precisely what I didn't need.
>>
>>>I know what /z does, since I have used it with COPY.
>>
>>>Can you demonstrate /Z working?
>>
>>>If Ixcopy/z a file to a mapped network drive, and do ctrl-c the
>>>destination file disappears.
>>
>>That is to be expected, Ctrl-C stops the execution of the command or the
>>batch script. When you do Ctrl-C you killXcopy, how can you then
>>expect it to resume?
>>
>
>
> With copy /z where src or dest is a network drive, Ctrl-C does not
> delete the dest file.
> With xcopy, whether /z or not, it does delete it.

It doesn't matter what copy does or doesn't do, xcopy works differently,
xcopy is not copy. That the two commands behave differently is nothing
surprising to me. If you kill xcopy before it finishes copying files it
doesn't save partial corupt files.

John

 

[John John (MVP)]

Re: xcopy /z and resuming - and the no percentage

jameshanley39@yahoo.co.uk wrote:

> On Jul 4, 6:20 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
>
>>jameshanle...@yahoo.co.uk wrote:
>>
>>>On Jul 4, 12:17 pm, "John John (MVP)" <audetw...@nbnet.nb.ca> wrote:
>>
>>>>/Z Copies networked files in restartable mode.
>>
>>>>IfXcopydoesn't do what you want then you will have to find another
>>>>utility to fill your needs. There isn't much we can do about whatxcopy
>>>>does or doesn't do by design.
>>
>>>>John
>>
>>>>xcopy/?
>>
>>>that is precisely what I didn't need.
>>
>>>I know what /z does, since I have used it with COPY.
>>
>>>Can you demonstrate /Z working?
>>
>>>If Ixcopy/z a file to a mapped network drive, and do ctrl-c the
>>>destination file disappears.
>>
>>That is to be expected, Ctrl-C stops the execution of the command or the
>>batch script. When you do Ctrl-C you killXcopy, how can you then
>>expect it to resume?
>>
>
>
> With copy /z where src or dest is a network drive, Ctrl-C does not
> delete the dest file.
> With xcopy, whether /z or not, it does delete it.
>
> I doubt one can explain how that is "Expected" , oter than just
> knowing that it behaves like that.

Yes it is perfectly expected! Unless you want incomplete corrupt files
saved to the disk why would you expect it to behave differently? Why do
you think that Xcopy should work in the same manner as copy? They are
different so it doesn't surprise me that they behave differently, what
makes you think that they should do the same thing?


> Regarding the "how can I expect it to resume" , see below.
>
>
>
>>The /Z switch is not meant to restartxcopyif it is killed, it is a
>>command toxcopyto tell it to retry the copy if it is interrupted by
>>other problems, like a drop in the network connection, thenXcopywill
>>retry the connection.
>
>
> That is not correct..
> Firstly, I wouldn't have expected that to be the case
> Secondly, according to my tests, that is not the case.

You completely missed the point. The /z switch instructs xcopy to retry
or restart if the network connection is dropped or lost, it doesn't
tell xcopy to restart itself after it is killed by user action or with
the use of Ctrl-C, which is all that I said, I never said that it would
not retry on a dropped network connection.

I xcopy doesn't do the job as you want it then maybe you should consider
using a different utility for your copy jobs.

John

 

[John John (MVP)]

Re: xcopy /z and resuming - and the no percentage

John wrote:

>>The /Z switch is not meant to restartxcopyif it is killed, it is a
>>command toxcopyto tell it to retry the copy if it is interrupted by
>>other problems, like a drop in the network connection, thenXcopywill
>>retry the connection.

jameshanley39@yahoo.co.uk wrote:

> That is not correct..

Yes, that is completely correct! The /z switch does not restart xcopy
if it is killed! It does tell xcopy to retry on dropped network
connections.



jameshanley39@yahoo.co.uk wrote:

> Firstly, I wouldn't have expected that to be the case
> Secondly, according to my tests, that is not the case.
>
> Even without /Z
> if you pull the cable out
> (e.g. at the router 'cos if you do it at the computer end, you get a
> popup, and windows starts thinking)
> I pulled the cat5 cable from the router.
> For 3 seconds. Then put it back in.
>
> The copy continued fine.

No one said that it wouldn't retry on a dropped connection, pulling the
network cable is not the same as "killing" xcopy.



jameshanley39@yahoo.co.uk wrote:

> If you actually tested /Z properly, then you'd have seen that what yo
> thought its function is, occurs even without it.

I have and I know what the switch does, you on the other hand were
expecting xcopy to resume after using the Ctrl-c key combination on it!
Something that no xcopy switch will surmount or overcome!



John wrote:

>>If you killxcopybefore it finishes copying the
>>file then the destination file is incomplete and corrupt and it will not
>>be saved to the disk in an incomplete and corrupt state.

jameshanley39@yahoo.co.uk wrote:

> Not true.
>
> If you had tested it, you'd know that was not true.
>
> The fc command would test the original file with the copied file, and
> prove that wasn't the case. That the dest file was not corrupted.
> And this is even without the /Z

Maybe you should read the documentation that ships with the utility or
the operating system, or that is available all over the web.

The /F switch simply displays source and destination file names while
copying. The /C switch is the bozo switch to tell xcopy to ignore
errors and keep on copying as if all was fine!

John

 

[jameshanley39@yahoo.co.uk]

Re: xcopy /z and resuming - and the no percentage

John John (MVP) wrote:

> John wrote:
>
> > > The /Z switch is not meant to restartxcopyif it is killed, it is a
> > > command toxcopyto tell it to retry the copy if it is interrupted
> > > by other problems, like a drop in the network connection,
> > > thenXcopywill retry the connection.
>
> jameshanley39@yahoo.co.uk wrote:
>
> > That is not correct..
>
> Yes, that is completely correct! The /z switch does not restart
> xcopy if it is killed! It does tell xcopy to retry on dropped
> network connections.
>

this retrying occurs Anyway.

pull the network cable out the router for 3 seconds, and the network
copy is fine. Pull it out for longer and it will exit to the shell.

Whether /Z or not.

So it is clearly not /Z that is causing retries without exitting.

I have actually shown an example of /Z, showing what it does. The
example involved - not me killing the command window with ctrl-c or
closing it. But with creating a network problem by pulling out the
network cable for a while - which killed the xcopy command. It made
xcopy copy some on one copy, and the rest on my next execution of
xcopy. An effect one didn't get without /Z

Can you demonstrate an example of /Z. You can include pulling out a
network cable in your demonstration. Or anything.
And To prove it is an example of /Z, obviously the result would have to
be different had /Z not been done.

So far you have just talked about how /Z makes it retry. But it retries
anyway. So if anything, your example just shows that /Z doesn't do that.


ps: sorry for the duplicate post appearing many times, there is some
problem with the google usenet interface. So I am using my news reader
client now.
<snip>