Copy progress?
IanC
remote PC (slowish connection).
I'm using copy "W:\filename.ext" "E:\filename.ext" where W is a remote
drive.
If I use Windows Explorer to drag/drop the file I get a progress bar giving
the estimated time remaining and a progress bar. I'm pretty certain I can't
get the same thing (unless I can somehow initiate the Explorer process
through a batch file, but is there something I could use to tick off the
progress? The ideal would be an update every couple of seconds showing how
much has been copied (and the size of the file), but a dot printed to the
screen every so often would be almost as good. Admittedly, this would only
give me a rough idea of the progress, but it's better than the flashing
cursor I have now.
Many thanks.
--
Ian
--
Herbert Kleebauer
echo a>E:\filename.___
echo @echo off>_.bat
echo :loop>>_.bat
echo cls >>_.bat
echo for %%%%i in (E:\filename.ext) do echo %%%%~zi>>_.bat
echo ping -n 2 127.0.0.1 ^>nul>>_.bat
echo if exist E:\filename.___ goto :loop>>_.bat
echo exit>>_.bat
start _.bat
copy "D:\filename.ext" "E:\filename.ext"
del E:\filename.___
ping -n 3 127.0.0.1 >nul
del _.bat
Ted Davis
Use Windows Explorer - otherwise you need a third party copy program that
runs as a Windows executable. However, why you would want to slow down an
already slow process escapes me: any monitor running in the single
tasking DOS emulator is going to have to add overhead to the copy
process to monitor the copy and generate the display. Note that Explorer
copies much slower than COPY from a CMD prompt.
--
T.E.D. (tda...@mst.edu) MST (Missouri University of Science and Technology)
used to be UMR (University of Missouri - Rolla).
billious
"IanC" <m...@me.com> wrote in message news:fJnbk.7406$jB5...@newsfe05.ams2...
Strange as it might seem, if all that is required is some variety of
activity indicator, perhaps you could use a compression utility like WZZIP,
then unzip the compressed file locally. The utility would give you some sort
of screen activity, the decompress and delete could be redirected to nul and
would be comparitively quick.
Todd Vargo
You could roll your own copy utility using VBScript with the Cscript host.
For a demo, save the following VBScript as mycopy.vbs and run it using...
cscript /nologo mycopy.vbs
If it does what you wanted, you can modify it to receive the source and
destination on the command line as well as add input error checking and
whatever other improvements can be imagined.
'mycopy.vbs
src = "W:\filename.ext"
dst = "E:\filename.ext"
Const ForReading = 1, ForWriting = 2
Set fso = CreateObject("Scripting.FileSystemObject")
fs = fso.GetFile(src).Size
Set f1 = fso.OpenTextFile(src, ForReading)
Set f2 = fso.OpenTextFile(dst, ForWriting, True)
For i = 0 to fs Step 4096
If i > fs Then
s = f1.Read(4096-(i-fs))
f2.Write s
Exit For
End If
s = f1.Read(4096)
f2.Write s
progress(i/fs*100)
Wscript.Sleep 10
Next
WScript.Echo vbCR & "done." & Space(20)
Function progress(value)
ind = Int(value / 5)
indicator = String(ind, 219) & String(19 - ind, 176) & " " & Int(value) &
"%"
WScript.StdOut.Write vbCR & indicator
End Function
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
TWayne
XXCopy.exe, easily available, is an xcopy.exe super-set and includes a
progress bar. Works great, use it all the time for my special needs
backups; the ones that are supposed to be so quick but which I keep
adding to<g>.
www.xxcopy.com IIRC.Free and paid versions; well worth the small price.
mycow
Ian - will this command switch provide you the progress you desire?
Copy /Z "W:\filename.ext" "E:\filename.ext"
IanC
/Z is described as "copies networked files in restartable mode." This
suggests that if the network connection is lost, the download will continue
from the point of loss when the attempt is made again. This doesn't seem to
be the case. Have I misunderstood the meaning?
--
Ian
--
"mycow" <my...@sbcglobal.net> wrote in message
news:Mwidk.11923$cW3....@nlpi064.nbdc.sbc.com...
jameshanley39
> Thanks, mycow. That's EXACTLY what I need.
>
> /Z is described as "copies networked files in restartable mode." This
> suggests that if the network connection is lost, the download will continue
> from the point of loss when the attempt is made again. This doesn't seem to
> be the case. Have I misunderstood the meaning?
>
> --
> Ian
My studies of xcopy and copy provided me with the knowledge to reply!
it is odd that copy /z gives a progress indicator, but xcopy /z
doesn't.
both are documented in /? not as giving a progress indicator, but as
you said, about restarting network downloads.
"/Z Copies networked files in restartable mode."
I did investigate it..
What it really means is resume not restart.
I don't think copy or xcopy works on network paths of the for \\ip or \
\compname. So I mapped a network drive.
Forget /Z for a moment,
If a file is being copied and there is a network error, like the cable
is removed, and put back within a brief time. With or Without /z ,
The copy continues. The file comes out fine. You can do the FC command
FC file1 file2 , to compare them, and they
This has to be a function of TCP/IP, that packets are numbered and od
packets are lost they can be requested.
If however you pull the cable out and keep it out.
It may be cleaner to do this at the router because then you don't get
a popup in windows that a network cable has been removed and an x. But
it has the same effect on the copy anyway.
So , if you pull the cable out and keep it out.
The copy exits and returns to the cmd shell
I think the file remains there.
If you then do the copy command again, set to overwrite that file, so
specifying that file at dest. Then it will restart the whole
download, it won't resume.
If you want the file to be able to resume when you do a copy after a
copy failed like that.
Then, you have to do
copy /z or xcopy /z For both the first and second copy.
So
xcopy /z filea fileb
CABLE OUT FOR A WHILE. LET IT EXIT TO SHELL
xcopy /z filea fileb
SAY YES, LET IT OVERWRITE.
And it resumes the copy.
I checked this with a hex editor called XVI32.
Whether you do /z or not, copy or xcopy, it creates a file at dest
equal in size as the source file, (with 0s I think). and it starts
filling/writing it.
I guess this ensures that for any one file there is enough disk space.
By going to the end of the file and finding the first non-zero string
or something like that, I could see the end of the writing of the file
and see it had progressed. Infact it reflected perfectly the
percentage shown by COPY.
And if I did the first copy for a long while, so the write went quite
far into the file. Then the second copy just a bit, then I checked hte
file and it had resumed and the write went a bit further.
If either the first copy or the second copy was not done with /z then
it didn't resume.
copy /z actually gives a progress indicator so it's easier to see it
has resumed.
xcopy /z does not
I don't know what you mean when you said it "doesn't restart".
what you had in mind.
If the cable is out long enough that it returns to the shell. Then it
won't repeat the command for you, that's for sure!
If it's out for a short period then it won't exit the shell, it will
resume, but that's regardless of whether you do /z or not
there are some intricacies/idiosyncracies about breaking the copy with
ctrl-c or closing a command prompt window. I don't think a non-network
copy can resume at all. And even network copies might require a
network error to resume. To resume would require that the file remains
after the copy (which does always happen with network errors I think),
and some other errors too. But just a file remaining is not enough for
a resume. It has to be a copy to a network drive, with copy or xcopy /
z and a network error. I think. Anyhow..
refs - 2 threads:
thread: xcopy /z and resuming - and the no percentage Options
ng: microsoft.public.windowsnt.misc
link:
http://groups.google.com/group/microsoft.public.windowsnt.misc/browse_frm/thread/6c2fc2b45904bc5e/acb166b266df9d90
or
http://tinyurl.com/6hl5va
date- early july 2008
thread: microsoft.public.windowsxp.general
link: http://groups.google.com/group/microsoft.public.windowsxp.general/browse_frm/thread/933cad724d3c7307/739edba0e4afbf4eba0e4afbf4e
or
http://tinyurl.com/6xfgxl
date- early july 2008