This project is read-only.

Extract Progress Event Question/Request

Sep 18, 2008 at 1:22 AM
I have been looking over the latest preview release and was really happy to see the progress event feature for extraction.  As I started digging into it, I noticed that I cannot seem to find a property to indicate the current number of bytes extract and the total number of bytes for the current entry be processed -- am I missing something and is there a way to get this information?  Also it would be great to get a file comment in the progress event.$0$0$0$0Thanks for a great piece of code! It really has make my job easier.$0
Sep 18, 2008 at 1:32 AM
Hmm, I think I see where some of my confusion is :)  The current event is for progress between entries not for a specific entry.  $0$0$0$0What I would like to do is beable to display progress when extracting really large files (each entry is > 200MB). Since this is a CPU and time intensive operation, I would like to have a progress bar in my application for processing the entire archive as well as for each file in the archive.$0$0$0$0$0Any chance you could add an event for that?  $0
Sep 18, 2008 at 4:27 AM
I will open a work item.
Not sure when I can get to it though!

ps: Do you care to test the Unicode support?
Sep 18, 2008 at 7:25 PM
Sure, I'd be happy to help test out with Unicode support.  Are you looking for any specific test cases?
Sep 19, 2008 at 8:49 PM
I'd like you to try it out; in fact I'd like everyone to try it out. The unicode stuff is in the latest v1.6 prelim release availalble on the releases tab. 

For tests: 
Use the library to zip up files that have "unicode filenames", or more accurately, filenames with characters that cannot be represented in 7-bit ASCII.  This might be characters with umlauts, tildes, and so on, in addition to characters from the non-Latin languages (Hebrew, Greek, Cyrillic, etc). 

See if it works, see if the files zip up and unzip properly.  See if the files open in Explorer the way you expect.  See if it works intuitively, if the library behaves the way you would like it to behave.  That kind of thing.

You will have to check the doc on the UseUnicode property on the ZipFile to see the options and the details of the implementation.  I encourage you to try all your tests with that flag both ON and OFF - to see how it behaves and what you would prefer. 

If find something that breaks, or surprises you, then please do report it.  If you are really ambitious, you can write up a test case that reproduces the problem you observed and attach it to a new workitem. 

The new Unicode support in the library is easy to describe, but it is hard for me to test, and it is hard for me to know if I am testing the right things.  So I need help on this, before I can declare the unicode support useful and stable.

Jan 29, 2009 at 1:04 PM
Edited Jan 29, 2009 at 1:05 PM
Can you please update us if this feature has been added yet or what is the progress on this?

Thanks in advance.
Feb 2, 2009 at 7:14 PM
Edited Feb 2, 2009 at 7:17 PM
yes, Unicode support is in the v1.6 final release.
Check the release s tab - Unicode support is noted as a key feature in v1.6.
Also check the doc on how it works.

The Unicode capability in the library was improved for v1.7, particularly in edge cases - but v1.7 is not yet stable and final. Again, check the releases tab and the documentation for full information.

If you are asking about the progress events - yes, the eventing was updated in v1.7 to satisfy this request.  Again, v1.7 is not final. Check the docs and examples for how it works. 

Feb 3, 2009 at 11:24 PM
Edited Feb 3, 2009 at 11:29 PM
Hi Cheeso & alag20,

Right 1.6 support Unicode but 1.7 is the only one to respect Zip specifications specifically regarding Unicode support.

Alag20, I don't know what is your final goal but using Unicode with 1.6 suppose that all entries will be encoded using Unicode, and don't forget that the Zip specification says that only chars which are not in IBM437 (which support most of wertern europe charsets) should be encode in Unicode.

The main drawback of using Unicode, is that Windows and others archivers doesn't support entries encoded in Unicode ...

My advice is :
If most of your zip files doesn't contains entries that need to be encoded in Unicode, use 1.7.

I use every day 1.7 in production environment, and I am very surprised of the good quality of this version.
Also you will get all amazing features of 1.7 version :
- Zlib algorithm (faster than .net)
- Support of compression level

I hope Cheeso will push this version to final soon !  :)
Feb 4, 2009 at 10:40 AM
Hi Cheeso, Dom Z,
Sorry for not clarifying my question properly, i meant what is the progress on Extract Progress event specifying what percentage of file [individual file / total zip] has been extracted?

I don't really need to use Unicode, but it is a major improvement.

Thanks in advance..
Greatly appreciate your work:)
Feb 4, 2009 at 5:31 PM
Edited Feb 4, 2009 at 5:48 PM
see v1.7 for that capability. there are events like ExtractProgress and SaveProgress that provide the bytes "so far" and the total bytes for an entry.