xcopy /z and resuming - and the no percentage

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

[Guest jameshanley39@yahoo.co.uk]

xcopy /z does nothing ! (win xp sp2)

 

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.

[Guest John John (MVP)]

Re: 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@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.

[Guest jameshanley39@yahoo.co.uk]

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

 

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.

[Guest jameshanley39@yahoo.co.uk]

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

 

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.

[Guest jameshanley39@yahoo.co.uk]

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

 

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.

[Guest John John (MVP)]

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

 

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

[Guest jameshanley39@yahoo.co.uk]

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

 

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.

[Guest jameshanley39@yahoo.co.uk]

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

 

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.

[Guest jameshanley39@yahoo.co.uk]

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

 

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.

[Guest John John (MVP)]

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

 

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

[Guest John John (MVP)]

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

 

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

[Guest John John (MVP)]

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

 

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

[Guest jameshanley39@yahoo.co.uk]

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

 

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>