xcopy /z and resuming - and the no percentage

On Jul 4, 6:20 pm, "John John (MVP)" <audetw... DeleteThis @nbnet.nb.ca> wrote:
> jameshanle... DeleteThis @yahoo.co.uk wrote:
> > On Jul 4, 12:17 pm, "John John (MVP)" <audetw... DeleteThis @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.

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... RemoveThis @nbnet.nb.ca> wrote:
> jameshanle... RemoveThis @yahoo.co.uk wrote:
> > On Jul 4, 12:17 pm, "John John (MVP)" <audetw... RemoveThis @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.