 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Server Forum / Windows NT / General Topics / July 2008xcopy /z and resuming - and the no percentage
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, 6:26 am, "jameshanle...@yahoo.co.uk" <jameshanle...@yahoo.co.uk> wrote: > I know that copy /z gives a percentage. > [quoted text clipped - 17 lines] > 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. /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. > I know that copy /z gives a percentage. > [quoted text clipped - 17 lines] > copies, like (or i.e. rather) copying to a mapped network drive. So I > am referring to that. > /Z Copies networked files in restartable mode. > [quoted text clipped - 5 lines] > > 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...@yahoo.co.uk> wrote: > > /Z Copies networked files in restartable mode. > [quoted text clipped - 31 lines] > 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...@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. >>/Z Copies networked files in restartable mode. >> [quoted text clipped - 14 lines] > 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 > jameshanle...@yahoo.co.uk wrote: > [quoted text clipped - 20 lines] > 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. >>jameshanle...@yahoo.co.uk wrote: >> [quoted text clipped - 27 lines] > 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. > [quoted text clipped - 6 lines] > 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 > jameshanle...@yahoo.co.uk wrote: > [quoted text clipped - 20 lines] > 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. >>jameshanle...@yahoo.co.uk wrote: >> [quoted text clipped - 24 lines] > 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 this post may appear a few times. It is identical. I had some trouble posting it > jameshanle...@yahoo.co.uk wrote: > [quoted text clipped - 20 lines] > 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 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. > 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. > Firstly, I wouldn't have expected that to be the case > Secondly, according to my tests, that is not the case. [quoted text clipped - 7 lines] > > 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. > 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. > Not true. > [quoted text clipped - 3 lines] > 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 > John wrote: > [quoted text clipped - 8 lines] > 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> |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.