XP CopyHere to a zip-file - when is it done ?

[R.Wieser]

Hello All,

Using XP I'm creating a .ZIP file and am copying some folders into it using
the CopyHere method

http://www.techcoil.com/blog/handy-vbscript-functions-for-dealing-with-zip-f
iles-and-folders )

The problem I have is the "when am I done?" method. The
"[namespace].items.count" method seems only to return the items in that
particular folder, ignoring any-and-all items in the subfolders.

This means that the "when am I done?" method might determine it is, while
there are still plenty of files in subfolders waiting to be copied (most
likely causing those files not to get copied at all, as the object is
cleaned up when the script terminates). :-(

Question: Is there another, preferrably simple*, method to get a "bit more"
accurate method to determine all copying is done ?

*meaning: not a "by hand" gathering and counting of the to-be-copied files.

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
Hello All,
Using XP I'm creating a .ZIP file and am copying some folders into it using
the CopyHere method
http://www.techcoil.com/blog/handy-vbscript-functions-for-dealing-with-zip-f
iles-and-folders )
The problem I have is the "when am I done?" method. The
"[namespace].items.count" method seems only to return the items in that
particular folder, ignoring any-and-all items in the subfolders.
This means that the "when am I done?" method might determine it is, while
there are still plenty of files in subfolders waiting to be copied (most
likely causing those files not to get copied at all, as the object is
cleaned up when the script terminates). :-(
Question: Is there another, preferrably simple*, method to get a "bit more"
accurate method to determine all copying is done ?
*meaning: not a "by hand" gathering and counting of the to-be-copied files.

If you're looking for the proper method, there's none. The shell's
"Compressed Folder" (i.e. ZIP support) shell extension doesn't provide any
mean to notify that the process of archiving file(s) has been completed. So,
you'll have to resort to your own method of checking it by at least polling.

What I could recommend is, after issuing CopyHere():

1. Poll the ZIP file to check its presence until it exists. Show an error
message if the file is still absent after e.g. 2 seconds. You'll need to
wait longer if the files to be archived are many enough to make the shell
takes more than 2 seconds to build the file list before it actually creates
the ZIP file. My suggestion for this problem is to show a prompt instead of
error message - prompting user whether to wait longer or to cancel the whole
script. VBScript simply doesn't have the capability to handle this problem.

2. Poll the ZIP file by opening the ZIP file with write access.

2.a. If it fails (i.e. Access Denied error), it means that the ZIP file is
still in use. Meaning that the archiving operation has not finished yet. So,
generate a delay then repeat step #2.

2.b. If it succeeded, it means that the archiving operation has finished.
So, close the file then you're finished.

[R.Wieser]

JJ,

Post by JJ
2. Poll the ZIP file by opening the ZIP file with write access.

Good one, didn't think of that.

And I take it you mean append access (I take it opening it for writing would
result in an empty file)

Regards,
Rudy Wieser

Post by JJ

Post by R.Wieser
Hello All,
Using XP I'm creating a .ZIP file and am copying some folders into it using
the CopyHere method

http://www.techcoil.com/blog/handy-vbscript-functions-for-dealing-with-zip-f

Post by JJ

Post by R.Wieser
iles-and-folders )
The problem I have is the "when am I done?" method. The
"[namespace].items.count" method seems only to return the items in that
particular folder, ignoring any-and-all items in the subfolders.
This means that the "when am I done?" method might determine it is, while
there are still plenty of files in subfolders waiting to be copied (most
likely causing those files not to get copied at all, as the object is
cleaned up when the script terminates). :-(
Question: Is there another, preferrably simple*, method to get a "bit more"
accurate method to determine all copying is done ?
*meaning: not a "by hand" gathering and counting of the to-be-copied files.

If you're looking for the proper method, there's none. The shell's
"Compressed Folder" (i.e. ZIP support) shell extension doesn't provide any
mean to notify that the process of archiving file(s) has been completed. So,
you'll have to resort to your own method of checking it by at least polling.
1. Poll the ZIP file to check its presence until it exists. Show an error
message if the file is still absent after e.g. 2 seconds. You'll need to
wait longer if the files to be archived are many enough to make the shell
takes more than 2 seconds to build the file list before it actually creates
the ZIP file. My suggestion for this problem is to show a prompt instead of
error message - prompting user whether to wait longer or to cancel the whole
script. VBScript simply doesn't have the capability to handle this problem.
2. Poll the ZIP file by opening the ZIP file with write access.
2.a. If it fails (i.e. Access Denied error), it means that the ZIP file is
still in use. Meaning that the archiving operation has not finished yet. So,
generate a delay then repeat step #2.
2.b. If it succeeded, it means that the archiving operation has finished.
So, close the file then you're finished.

[Evertjan.]

Post by R.Wieser

Post by JJ
2. Poll the ZIP file by opening the ZIP file with write access.

Good one, didn't think of that.
And I take it you mean append access (I take it opening it for writing
would result in an empty file)

I doubt that 'opening for writing' does that.

I suppose only the write action itself empties the file,
but better test my supposition first.

[R.Wieser]

Evertjan,

Post by Evertjan.
I doubt that 'opening for writing' does that.
I suppose only the write action itself empties the file,
but better test my supposition first.

I just tested it to be sure using "(using
fso.OpenTextFile("foobar.zip",2,True)" as wel as with the last argument set
to False, and both caused the zipfile to be emptied out (zero-sized file).

It was to be expected, as I'm dealing with a textfile. For a binary file it
would expect it to be different.


And something worth knowing: as long as the CopyHere action has actually
been started by the object (instead of waiting for a previous action to
finish) before the script terminates the action will fully complete.

@all:
A related question though: The webpage I mentioned in my initial message
creates a folder object from the zipfile name: "Set zip =
sa.NameSpace(pathToZipFile)"

Is there a way to reverse that method, and get a pathname back from that
folder/namespace object ? I've been looking at the folder object, but it
does not seem to have a "name" (or alike) property or related method ...

Regards,
Rudy Wieser

Post by Evertjan.

Post by R.Wieser

Post by JJ
2. Poll the ZIP file by opening the ZIP file with write access.

Good one, didn't think of that.
And I take it you mean append access (I take it opening it for writing
would result in an empty file)

I doubt that 'opening for writing' does that.
I suppose only the write action itself empties the file,
but better test my supposition first.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[JJ]

Post by R.Wieser
A related question though: The webpage I mentioned in my initial message
creates a folder object from the zipfile name: "Set zip =
sa.NameSpace(pathToZipFile)"
Is there a way to reverse that method, and get a pathname back from that
folder/namespace object ? I've been looking at the folder object, but it
does not seem to have a "name" (or alike) property or related method ...

wscript.echo zip.parentfolder.parsename(zip.title).path

I admit it tho, the shell can be confusing.
I would probably blame it all to MSDN.

[JJ]

Post by JJ
wscript.echo zip.parentfolder.parsename(zip.title).path

Not truly object oriented, if I must say.
If it's truly object oriented, the "path" property should have been a member
of "zip" too (i.e. the Folder object. Not just the FolderItem object).

[R.Wieser]

JJ,

Post by JJ
Not truly object oriented, if I must say.
If it's truly object oriented, the "path" property should have
been a member of "zip" too

:-) I agree. That "path" property was exactly what I was looking for, but
could not find.

And yes, I also noticed that the folder object itself was used twice, once
as an argument. ... which made me wonder: could I put other stuff there as
the argument.

Yep, that works (I used another folder objects title). The non-argument
stuff seems to specify the base folder, with the argument a file/foldername
that must be present in that base folder. Looking *back* that even make
sense. :-|

Regards,
Rudy Wieser


-- Origional message

Post by JJ

Post by JJ
wscript.echo zip.parentfolder.parsename(zip.title).path

Not truly object oriented, if I must say.
If it's truly object oriented, the "path" property should have been a member
of "zip" too (i.e. the Folder object. Not just the FolderItem object).

[R.Wieser]

JJ,

Post by JJ
wscript.echo zip.parentfolder.parsename(zip.title).path

Wow! I don't think I would ever be able to figure that out on my own.
Talk about a round-about way to do something ...

Post by JJ
I would probably blame it all to MSDN.

Isn't that the first thing on the "who to blame" flowchart ? Checking if
you can shift it to someone who isn't present and therefore can't object ?
:-)

But yes, I would too. The MSDN page about the folder object doesn't even
*hint* about being able to recover the file/folder name, let alone show how
its done. :-\

Thank you.

Regards,
Rudy Wieser

Post by JJ

Post by R.Wieser
A related question though: The webpage I mentioned in my initial message
creates a folder object from the zipfile name: "Set zip =
sa.NameSpace(pathToZipFile)"
Is there a way to reverse that method, and get a pathname back from that
folder/namespace object ? I've been looking at the folder object, but it
does not seem to have a "name" (or alike) property or related method ...

wscript.echo zip.parentfolder.parsename(zip.title).path
I admit it tho, the shell can be confusing.
I would probably blame it all to MSDN.

[JJ]

Post by R.Wieser
And I take it you mean append access (I take it opening it for writing would
result in an empty file)

Using write mode in BASIC (AFAIK, any variant) would mean to open then
truncate the file. With append mode, it opens then seek to EOF.

[R.Wieser]

JJ,

Post by JJ
Using write mode in BASIC (AFAIK, any variant) would mean to open
then truncate the file. With append mode, it opens then seek to EOF.

As it turns out, VBScript responds the same (and I can't remember any other
scripting language doing it, for text-mode access, differently).

Regards,
Rudy Wieser

Post by JJ

Post by R.Wieser
And I take it you mean append access (I take it opening it for writing would
result in an empty file)

Using write mode in BASIC (AFAIK, any variant) would mean to open then
truncate the file. With append mode, it opens then seek to EOF.

[Dave "Crash" Dummy]

Post by R.Wieser
Hello All,
Using XP I'm creating a .ZIP file and am copying some folders into it
using the CopyHere method
http://www.techcoil.com/blog/handy-vbscript-functions-for-dealing-with-zip-f
iles-and-folders )
The problem I have is the "when am I done?" method. The
"[namespace].items.count" method seems only to return the items in
that particular folder, ignoring any-and-all items in the subfolders.
This means that the "when am I done?" method might determine it is,
while there are still plenty of files in subfolders waiting to be
copied (most likely causing those files not to get copied at all, as
the object is cleaned up when the script terminates). :-(
Question: Is there another, preferrably simple*, method to get a "bit
more" accurate method to determine all copying is done ?
*meaning: not a "by hand" gathering and counting of the to-be-copied files.

I cheat. I use the RUN command to run 7z.exe, the command line version
of 7-Zip. The command line parameters and switches give plenty of
flexibility, and the RUN command has the wait until done option.

To see the 7z commands, run "d:\path\7z.exe > comline.txt" in a command box.

[R.Wieser]

Dave,

Post by Dave "Crash" Dummy
I cheat. I use the RUN command to run 7z.exe

Thanks for the suggestion, but alas, I can only use whats already on the
target computer, hence the use of VBScript. But yes, that would be my
choice too. :-)

FYI, the "keep trying to open for append, repreat until success" seems to
work like a charm.

Regards,
Rudy Wieser

Post by Dave "Crash" Dummy

Post by R.Wieser
Hello All,
Using XP I'm creating a .ZIP file and am copying some folders into it
using the CopyHere method

http://www.techcoil.com/blog/handy-vbscript-functions-for-dealing-with-zip-f

Post by Dave "Crash" Dummy

Post by R.Wieser
iles-and-folders )
The problem I have is the "when am I done?" method. The
"[namespace].items.count" method seems only to return the items in
that particular folder, ignoring any-and-all items in the subfolders.
This means that the "when am I done?" method might determine it is,
while there are still plenty of files in subfolders waiting to be
copied (most likely causing those files not to get copied at all, as
the object is cleaned up when the script terminates). :-(
Question: Is there another, preferrably simple*, method to get a "bit
more" accurate method to determine all copying is done ?
*meaning: not a "by hand" gathering and counting of the to-be-copied files.

I cheat. I use the RUN command to run 7z.exe, the command line version
of 7-Zip. The command line parameters and switches give plenty of
flexibility, and the RUN command has the wait until done option.
To see the 7z commands, run "d:\path\7z.exe > comline.txt" in a command box.
--
Crash
"Sometimes a cigar is just a cigar."
~ Sigmund Freud ~