Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
zip API
65 views
Skip to first unread message
Friedel Jantzen
Apr 8, 2013, 2:55:32 AM4/8/13
to
Hello,
files can be copied to a zip folder using Folder->CopyHere.
The problem is, that afaik the caller is not not notified, when the
(un-)zipping has finished. A solution is counting the files in the
destination zip folder. But this is not as easy, if there are already files
with the same names in the destination zip.
If the app exits before the (un)zipping is complete, zipping will not be
continued.
I tried this
http://blogs.msdn.com/oldnewthing/archive/2008/05/28/8555658.aspx
but it does not work for zipping.
So are there another Win32 APIs for zipping, which provide a better control
of the zipping process?
If not, can you recommend reliable libraries for this?
TIA,
Friedel
files can be copied to a zip folder using Folder->CopyHere.
The problem is, that afaik the caller is not not notified, when the
(un-)zipping has finished. A solution is counting the files in the
destination zip folder. But this is not as easy, if there are already files
with the same names in the destination zip.
If the app exits before the (un)zipping is complete, zipping will not be
continued.
I tried this
http://blogs.msdn.com/oldnewthing/archive/2008/05/28/8555658.aspx
but it does not work for zipping.
So are there another Win32 APIs for zipping, which provide a better control
of the zipping process?
If not, can you recommend reliable libraries for this?
TIA,
Friedel
Deanna Earley
Apr 8, 2013, 4:18:15 AM4/8/13
to
On 08/04/2013 07:55, Friedel Jantzen wrote:
> Hello,
> files can be copied to a zip folder using Folder->CopyHere.
> The problem is, that afaik the caller is not not notified, when the
> (un-)zipping has finished. A solution is counting the files in the
> destination zip folder. But this is not as easy, if there are already files
> with the same names in the destination zip.
> If the app exits before the (un)zipping is complete, zipping will not be
> continued.
>
> I tried this
> http://blogs.msdn.com/oldnewthing/archive/2008/05/28/8555658.aspx
> but it does not work for zipping.
Hijacking the shell is inherently going to be "limited".
> Hello,
> files can be copied to a zip folder using Folder->CopyHere.
> The problem is, that afaik the caller is not not notified, when the
> (un-)zipping has finished. A solution is counting the files in the
> destination zip folder. But this is not as easy, if there are already files
> with the same names in the destination zip.
> If the app exits before the (un)zipping is complete, zipping will not be
> continued.
>
> I tried this
> http://blogs.msdn.com/oldnewthing/archive/2008/05/28/8555658.aspx
> but it does not work for zipping.
> So are there another Win32 APIs for zipping, which provide a better control
> of the zipping process?
> If not, can you recommend reliable libraries for this?
--
Deanna Earley (dee.e...@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/
iCode Systems
(Replies direct to my email address will be ignored. Please reply to the
group.)
R.Wieser
Apr 8, 2013, 7:20:18 AM4/8/13
to
Friedel,
> The problem is, that afaik the caller is not not notified,
> when the (un-)zipping has finished.
On my XP computer the ZIP capabilities of the OS are strictly aimed at
user-interaction, with the "CopyHere" as a needed function to be able to
complete the users wishes. Full programmatically interaction is therefore
not really possible, and any-and-all attempts to do so lead into the dreaded
quicksand of the "work-arounds".
Oh, by the way: Those ZIP capabilities are the result of, as so many times
with MS, a third-part product. One that could have been minimalized in
functionality on purpose, as an "incentive" for you to buy the whole package
from the origional manufacturer. :-)
> If not, can you recommend reliable libraries for this?
I myself have Unzip32, Rar and ZLib1 here. I can say that most of them are
aimed at the above-mentioned user-interaction, with programmatic access as
an afterthought/side-effect.
The first one in my list has, for example, only human-readable output with
no possibilities to get a files size, attributes, search for particular file
and other stuf like it. Rar has got the same kind of problems. ZLib1 can
only handle single files (cannot do anthing with a PKZip file, but can
extract a single file if you point it out), and has no clue what to do with
backslashes in a filepath.
The 7Zip interface mentioned by Deanna is aimed at OOP (Object Oriented
Programming), which might not be supported by your programming-language of
choice.
In short, it will be a queeste to find an API you can really use as you
would want it. :-\
Regards,
Rudy Wieser
-- Origional message:
Friedel Jantzen <nospa...@freenet.de> schreef in berichtnieuws
okkrejggbl7o.1m...@40tude.net...
> The problem is, that afaik the caller is not not notified,
> when the (un-)zipping has finished.
user-interaction, with the "CopyHere" as a needed function to be able to
complete the users wishes. Full programmatically interaction is therefore
not really possible, and any-and-all attempts to do so lead into the dreaded
quicksand of the "work-arounds".
Oh, by the way: Those ZIP capabilities are the result of, as so many times
with MS, a third-part product. One that could have been minimalized in
functionality on purpose, as an "incentive" for you to buy the whole package
from the origional manufacturer. :-)
> If not, can you recommend reliable libraries for this?
aimed at the above-mentioned user-interaction, with programmatic access as
an afterthought/side-effect.
The first one in my list has, for example, only human-readable output with
no possibilities to get a files size, attributes, search for particular file
and other stuf like it. Rar has got the same kind of problems. ZLib1 can
only handle single files (cannot do anthing with a PKZip file, but can
extract a single file if you point it out), and has no clue what to do with
backslashes in a filepath.
The 7Zip interface mentioned by Deanna is aimed at OOP (Object Oriented
Programming), which might not be supported by your programming-language of
choice.
In short, it will be a queeste to find an API you can really use as you
would want it. :-\
Regards,
Rudy Wieser
-- Origional message:
Friedel Jantzen <nospa...@freenet.de> schreef in berichtnieuws
okkrejggbl7o.1m...@40tude.net...
Geoff
Apr 8, 2013, 11:31:56 AM4/8/13
to
ZipFile class but all the examples are in C#. I don't know if you can
adapt it to MS C++.
http://msdn.microsoft.com/en-us/library/ms404280(v=vs.110).aspx
All zip management within applications so far have been via 3rd party
libraries like gzip by Mark Adler and Jean-loup Gailly.
http://www.zlib.net/
Friedel Jantzen
Apr 9, 2013, 1:30:52 AM4/9/13
to
Thank you, Deanna, Rudy, and Geoff for your replies.
I used zlib and zlibwapi earlier. If there is no Win32 zip API, I'll go on
with them, because they are implemented in small DLLs and updated.
I used zlib and zlibwapi earlier. If there is no Win32 zip API, I'll go on
with them, because they are implemented in small DLLs and updated.
Christian ASTOR
Apr 9, 2013, 1:08:51 PM4/9/13
to
Friedel Jantzen a �crit :
namespace (IShellFolder, IEnumIDList)
> Hello,
> files can be copied to a zip folder using Folder->CopyHere.
> The problem is, that afaik the caller is not not notified, when the
> (un-)zipping has finished.
To unzip, it can be done with registered zipfldr.dll and the shell
> files can be copied to a zip folder using Folder->CopyHere.
> The problem is, that afaik the caller is not not notified, when the
> (un-)zipping has finished.
namespace (IShellFolder, IEnumIDList)
Friedel Jantzen
Apr 10, 2013, 9:41:52 AM4/10/13
to
I'll look for informations about this on the web.
(Until now I use FolderItems->get_Count() to count the files.)
Regards,
Friedel
R.Wieser
Apr 10, 2013, 12:56:59 PM4/10/13
to
Friedel,
> Until now I use FolderItems->get_Count() to count the files.
There are at least two problems I'm aware of with that method of checking if
all files are extracted:
1) The file could not be extracted,
2) the extracted file could not be written
So be carefull.
Regards,
Rudy Wieser
-- Origional message
Friedel Jantzen <nospa...@freenet.de> schreef in berichtnieuws
1pcxexor1uo05.1...@40tude.net...
> Until now I use FolderItems->get_Count() to count the files.
all files are extracted:
1) The file could not be extracted,
2) the extracted file could not be written
So be carefull.
Regards,
Rudy Wieser
-- Origional message
Friedel Jantzen <nospa...@freenet.de> schreef in berichtnieuws
Friedel Jantzen
Apr 11, 2013, 3:15:00 AM4/11/13
to
Am Wed, 10 Apr 2013 18:56:59 +0200 schrieb R.Wieser:
> ...
Does this mean: If I count the files in the destination folder like above,
that this could count a file, which actually has not been written to the
destination?
Regards,
Friedel
> ...
>> Until now I use FolderItems->get_Count() to count the files.
>
> There are at least two problems I'm aware of with that method of checking if
> all files are extracted:
> 1) The file could not be extracted,
> 2) the extracted file could not be written
>
> So be carefull.
Thank you for your warnings, Rudy.
>
> There are at least two problems I'm aware of with that method of checking if
> all files are extracted:
> 1) The file could not be extracted,
> 2) the extracted file could not be written
>
> So be carefull.
Does this mean: If I count the files in the destination folder like above,
that this could count a file, which actually has not been written to the
destination?
Regards,
Friedel
R.Wieser
Apr 11, 2013, 12:06:48 PM4/11/13
to
Friedel,
> If I count the files in the destination folder like above, that
> this could count a file, which actually has not been written
> to the destination?
No, the other way around: you could *not* count a file which was *supposed
to be* stored into the target-folder.
I assumed you where talking about how to determine if all files where copied
(from the ZIP file to the folder, or the other way around). When you count
the number of files in the ZIP-file and than try to compare that with the
number of files copied from it and into the the target-folder it might go
wrong, for the reasons I named.
Hope that clarifies it.
Regards,
Rudy Wieser
-- Origional message:
Friedel Jantzen <nospa...@freenet.de> schreef in berichtnieuws
e5qsmz6ru291.1x...@40tude.net...
> If I count the files in the destination folder like above, that
> this could count a file, which actually has not been written
> to the destination?
to be* stored into the target-folder.
I assumed you where talking about how to determine if all files where copied
(from the ZIP file to the folder, or the other way around). When you count
the number of files in the ZIP-file and than try to compare that with the
number of files copied from it and into the the target-folder it might go
wrong, for the reasons I named.
Hope that clarifies it.
Regards,
Rudy Wieser
-- Origional message:
Friedel Jantzen <nospa...@freenet.de> schreef in berichtnieuws
Friedel Jantzen
Apr 12, 2013, 2:03:13 AM4/12/13
to
Hello Rudy!
Am Thu, 11 Apr 2013 18:06:48 +0200 schrieb R.Wieser:
> ...
On failure I would not get any error message and wait for completion
infinitely. I have never experienced this, but it is quite possible.
So using the zipping features of the shell is unreliable.
Regards,
Friedel
Am Thu, 11 Apr 2013 18:06:48 +0200 schrieb R.Wieser:
> ...
>> If I count the files in the destination folder like above, that
>> this could count a file, which actually has not been written
>> to the destination?
>
> No, the other way around: you could *not* count a file which was *supposed
> to be* stored into the target-folder.
>
> I assumed you where talking about how to determine if all files where copied
> (from the ZIP file to the folder, or the other way around). When you count
> the number of files in the ZIP-file and than try to compare that with the
> number of files copied from it and into the the target-folder it might go
> wrong, for the reasons I named.
>
> Hope that clarifies it.
Yes, thank you.
>> this could count a file, which actually has not been written
>> to the destination?
>
> No, the other way around: you could *not* count a file which was *supposed
> to be* stored into the target-folder.
>
> I assumed you where talking about how to determine if all files where copied
> (from the ZIP file to the folder, or the other way around). When you count
> the number of files in the ZIP-file and than try to compare that with the
> number of files copied from it and into the the target-folder it might go
> wrong, for the reasons I named.
>
> Hope that clarifies it.
On failure I would not get any error message and wait for completion
infinitely. I have never experienced this, but it is quite possible.
So using the zipping features of the shell is unreliable.
Regards,
Friedel
R.Wieser
Apr 12, 2013, 8:38:03 AM4/12/13
to
Friedel,
> On failure I would not get any error message and wait
> for completion infinitely.
Yep, thats exactly what I tried to warn you about.
> I have never experienced this, but it is quite possible.
Well, a file not being extracted/copied to the target-folder will not often
occur, but you need to be aware that it *can* happen (the ZIP file might be
damaged).
When you copy to a non-empty folder you also must check if a file in that
folder gets overwritten (and thus not regarded as a new). Even in an empty
folder you could, for some reason, overwrite a just-extracted file, causing
the same problem.
> So using the zipping features of the shell is unreliable.
Yep, thats pretty-much it. :-\
Regards,
Rudy Wieser
-- Origional message:
Friedel Jantzen <nospa...@freenet.de> schreef in berichtnieuws
dp0zx20cwp7q.1lo0jhzykx6g2$.dlg@40tude.net...
> On failure I would not get any error message and wait
> for completion infinitely.
> I have never experienced this, but it is quite possible.
occur, but you need to be aware that it *can* happen (the ZIP file might be
damaged).
When you copy to a non-empty folder you also must check if a file in that
folder gets overwritten (and thus not regarded as a new). Even in an empty
folder you could, for some reason, overwrite a just-extracted file, causing
the same problem.
> So using the zipping features of the shell is unreliable.
Regards,
Rudy Wieser
-- Origional message:
Friedel Jantzen <nospa...@freenet.de> schreef in berichtnieuws
0 new messages