John John (MVP)

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)

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)

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

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>