xcopy /z and resuming - and the no percentage

/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.DeleteThis@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.

On Jul 4, 12:17 pm, "John John (MVP)" <audetw....RemoveThis@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.

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

On Jul 4, 5:43 pm, "jameshanle...@yahoo.co.uk"
<jameshanle... DeleteThis @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.

jameshanley39 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.
>>
>>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

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.
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.