zziplib-project Mailing List for ZZIPlib Library
Brought to you by:
guidod
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Hanno B. <ha...@hb...> - 2015-05-29 19:48:18
|
Hi, The attached file will cause a Bus error in unzzip. This is usually an indication of an invalid memory access at a low level. Address Sanitizer gives a stack trace of the issue: ==22690==ERROR: AddressSanitizer: SEGV on unknown address 0x7f226dbf5fd1 (pc 0x0000004dea9c bp 0x7ffd934fecf0 sp 0x7ffd934feb80 T0) #0 0x4dea9b in __zzip_parse_root_directory /mnt/ram/zziplib-0.13.62/Linux_4.0.4_x86_64.d/zzip/../../zzip/zip.c:475:15 #1 0x4e065d in __zzip_dir_parse /mnt/ram/zziplib-0.13.62/Linux_4.0.4_x86_64.d/zzip/../../zzip/zip.c:743:15 #2 0x4e065d in zzip_dir_fdopen_ext_io /mnt/ram/zziplib-0.13.62/Linux_4.0.4_x86_64.d/zzip/../../zzip/zip.c:701 #3 0x4e0dab in zzip_dir_open_ext_io /mnt/ram/zziplib-0.13.62/Linux_4.0.4_x86_64.d/zzip/../../zzip/zip.c:817:16 #4 0x4e0bf6 in zzip_dir_open /mnt/ram/zziplib-0.13.62/Linux_4.0.4_x86_64.d/zzip/../../zzip/zip.c:794:12 #5 0x4dd13d in main /mnt/ram/zziplib-0.13.62/Linux_4.0.4_x86_64.d/bins/../../bins/unzzip.c:52:15 #6 0x7f22d08d6f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f) #7 0x436b66 in _start (/mnt/ram/zziplib-0.13.62/Linux_4.0.4_x86_64.d/bins/unzzip+0x436b66) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /mnt/ram/zziplib-0.13.62/Linux_4.0.4_x86_64.d/zzip/../../zzip/zip.c:475 __zzip_parse_root_directory ==22690==ABORTING This issue was found with the tool american fuzzy lop. cu, -- -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hb... GPG: BBB51E42 |
From: Witold F. <wi...@po...> - 2008-05-21 19:31:07
|
Hi! I read docs, but I haven't found how to "read" a zip file, which is already in memory. I have unsigned char *block - start of the "zip file" and int length - length of block. How to read, parse, etc. from memory? -- Witek |
From: Didier G. <ld...@ul...> - 2008-05-03 10:20:53
|
Hi, Trying to compile zziplib 0.13.49 on tru64 5.1b and getting an error: (cd `uname -msr | tr " /" "__"`.d && test ! -f configure && gmake "all") || exit ; gmake done "RULE=all" gmake[1]: Entering directory `/usr/local/zziplib/zziplib-0.13.49/OSF1_V5.1_alpha.d' gmake all-recursive gmake[2]: Entering directory `/usr/local/zziplib/zziplib-0.13.49/OSF1_V5.1_alpha.d' Making all in zzip gmake[3]: Entering directory `/usr/local/zziplib/zziplib-0.13.49/OSF1_V5.1_alpha.d/zzip' source='../../zzip/zip.c' object='zip.lo' libtool=yes \ DEPDIR=.deps depmode=tru64 /usr/bin/posix/sh ../../uses/depcomp \ /usr/bin/posix/sh ../libtool --silent --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I.. -I../.. -I/usr/local/include -O4 -g3 -pthread -D_USE_MMAP -Wall -fstrict-prototypes -Wstrict-prototypes -Wpointer-arith -Wsign-compare -Wmissing-declarations -Wdeclaration-after-statement -Werror-implicit-function-declaration -c -o zip.lo ../../zzip/zip.c libtool: compile: libobj name `zip.lo' may not contain shell special characters. gmake[3]: *** [zip.lo] Error 1 gmake[3]: Leaving directory `/usr/local/zziplib/zziplib-0.13.49/OSF1_V5.1_alpha.d/zzip' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/local/zziplib/zziplib-0.13.49/OSF1_V5.1_alpha.d' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/local/zziplib/zziplib-0.13.49/OSF1_V5.1_alpha.d' gmake: *** [all] Error 2 I have updated many packages, gnu and others, including libtool, autoconf, automake, m4, pkg-config, and I tried using older versions of zziplib, such as 0.13.45, all the way back to 0.12.83 and always get errors. I even tried doing a autoreconf but it didn't fix the problem. Can you fix this? I'm using gnu make, and the tru64 native compiler. My libtool is the latest now, but the error was there with previous versions. -- Didier Godefroy mailto:dg...@ul... |
From: <tr...@gm...> - 2005-04-20 16:14:38
|
Hello... im having some trouble reading a real directory while the .zip file works fine. This is my code: ZZIP_DIR* dir =3D zzip_opendir("../data.zip"); // Works fine, but i can't read "../data" ZZIP_DIRENT dirent; while(zzip_dir_read(dir,&dirent)) { if(dirent.st_size) { =09cout << dirent.d_name << endl; } } zzip_dir_close(dir); What am i doing wrong? The docs says that zzip_opendir will browse both typ= es? Reading of a specifically specified file from a .zip or real directory works fine and as is should, the real file gets priority. |
From: <ben...@id...> - 2004-05-22 12:10:03
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Russell F. <rf3...@oh...> - 2004-03-08 11:56:48
|
> What's missing is the support for applications to automatically > generate newstyle zip files. In the linux world, we are generally > using the info-zip.org tools - which still has version 2.3 as > current released in 1999. The `future plans` section says that > a new generation "Zip 3.0 should be released sometime in > 2004, possibly as early as summer". > > Consequently, we still have some time left before the Great > New Zip Compression with bzip2 algorithmics is going to replace > zlib deflate everywhere. Sadly, I am not sure whether the libbzip2 > API will be maintained or that the code will be reworked to match > the libzip API style. These APIs are slightly different in fact. Therefore, > I am very unsure whether it is all too much a good idea to implant > some #ifdef/else into libzzip where in fact we do not know yet how > the Great New Zip Compression library and tools will look lik.e Well, in light of that, I do agree that it may be premature to implement the bz2 algorithms into zzlib. It is best to wait and see what "standards" emerge. The second part of my question is regarding the older more stagnant methods. Despite not being generated by the Info-Zip tools, their decompression is still supported. Do you think it is a good idea to add decompression routines for these older methods? Cheers, Russ |
From: Guido D. <gui...@gm...> - 2004-03-07 23:41:06
|
Russell Francis wrote: > Guido Draheim wrote: > >> >> >> Russell Francis wrote: >> >>> Hello, >>> >>> I am looking at this library and considering using it for an >>> application I am writing. It seems that zziplib only supports >>> decompression with zlib. Are there any plans to support other >>> decompression schemes in the future? >>> >>> If support for other methods [12 - bzip2, 6 - exploding) in >>> particular was submitted would you be inclined to include it with the >>> library? >>> >> >> The general "zip" tools will only produce *.zip files with compression >> type 0 or 8 (i.e. stored or (zlib) deflated). The usage of explode is >> long >> gone, the usage of bzip2 is not known to me. > > > This is true, but the fact that modern utilities don't create files with > these formats doesn't mean that we won't occasionally run into them. > > For example, I am working on an application http://gutenfetch.sf.net/. > This program queries and downloads electronic texts available from > Project Gutenberg. All of the etexts are stored in both plain text and > .ZIP file format. The first electronic text was put on the site in > 1980(?). Needless to say, I am running into quite a few zipped files > using older compression algorithms. > > I would agree that there is no need to implement compression schemes for > these old algorithms but decompression routines would be very handy for > me at least. :) > >> However, I gather that bzip2 support would be interesting for quite a >> few people. Do you know a compressor utility program that can make >> use libbzip2 ? > > > I believe that bzip2 compression is relatively new to the .ZIP file > format. You can find information about it here. > > http://www.pkware.com/products/enterprise/white_papers/appnote.html uh, oh, I did not know this reference. I'll add a link on the project webspace. > > Applications which support compression/decompression are springing up > slowly, but I am not sure how wide spread they are. I still think most > applications are reluctant to create .ZIP files using bzip compression > because it is not widely supported (Chicken & Egg ...). what's more interesting is the use of zip64 support. I do have some reports where people are packing rather large zip disks. > > This is a website of an application which can create bzip2 compressed > zip files. Since it is also in the PkWare format spec, I would imagine > that their commercial applications/libraries already do or will shortly > create these too. I think that Winzip can also decompress this type of > .ZIP file but am not positive about that. > > http://www.4zip.com/ > Just for the record - there was originally the challenge for better zlib compression a.k.a. next-generation gzip. At one point the zlib maintainers did stop listening to some proposals and there was a split-off. After a while of forgery in the dark on bzip, the developer surfaced with a different idea of the compression concept which was called bzip2 by then. Orignally, the algorithm was still buggy but it matured quickly and it was adopted quickly around also because its superior compression could be proven in an academic paper. Actually, the latter part happened now in the light amongst the well-known compressions gurus and with a proven new algorithm it was envisioned to merge the bzip2 algorithm into the command line tool frontend of gzip. Since the zlib algorithm is actually an extract of the pkware zip project it should be no surprise that pkware envisions to have bzip2 support in its toolchain. However, the actual merge of the bzip2 algorithm into gzip has been waited for years now, and only since late we see new developments to come about in the gzip/lib project. With those pieces of information, I can easily understand how there is suddenly a well-written specification of the zip file format about that also lists bzip2 as a compression method. However we should not be misguided to the impression that such tools have already shipped widely. It's still a reform of the toolchains that has just started. Nethertheless, the libzzip project was created especially to be able to unpack zip-compressed data files for applications, in which it is a lightweight library along with lots of support to just drop-in zzip-io calls in the very same places where otherwise file-io would be used. Bringing up better compression ratios for application writers is a good concept. What's missing is the support for applications to automatically generate newstyle zip files. In the linux world, we are generally using the info-zip.org tools - which still has version 2.3 as current released in 1999. The `future plans` section says that a new generation "Zip 3.0 should be released sometime in 2004, possibly as early as summer". Consequently, we still have some time left before the Great New Zip Compression with bzip2 algorithmics is going to replace zlib deflate everywhere. Sadly, I am not sure whether the libbzip2 API will be maintained or that the code will be reworked to match the libzip API style. These APIs are slightly different in fact. Therefore, I am very unsure whether it is all too much a good idea to implant some #ifdef/else into libzzip where in fact we do not know yet how the Great New Zip Compression library and tools will look lik.e cheers, -- guido http://google.de/search?q=guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(+-) r+@>+++ y++ 5++X- (geekcode) |
From: Russell F. <rf3...@oh...> - 2004-03-07 22:54:50
|
Guido Draheim wrote: > > > Russell Francis wrote: > >> Hello, >> >> I am looking at this library and considering using it for an >> application I am writing. It seems that zziplib only supports >> decompression with zlib. Are there any plans to support other >> decompression schemes in the future? >> >> If support for other methods [12 - bzip2, 6 - exploding) in particular >> was submitted would you be inclined to include it with the library? >> > > The general "zip" tools will only produce *.zip files with compression > type 0 or 8 (i.e. stored or (zlib) deflated). The usage of explode is long > gone, the usage of bzip2 is not known to me. This is true, but the fact that modern utilities don't create files with these formats doesn't mean that we won't occasionally run into them. For example, I am working on an application http://gutenfetch.sf.net/. This program queries and downloads electronic texts available from Project Gutenberg. All of the etexts are stored in both plain text and .ZIP file format. The first electronic text was put on the site in 1980(?). Needless to say, I am running into quite a few zipped files using older compression algorithms. I would agree that there is no need to implement compression schemes for these old algorithms but decompression routines would be very handy for me at least. :) > However, I gather that bzip2 support would be interesting for quite a > few people. Do you know a compressor utility program that can make > use libbzip2 ? I believe that bzip2 compression is relatively new to the .ZIP file format. You can find information about it here. http://www.pkware.com/products/enterprise/white_papers/appnote.html Applications which support compression/decompression are springing up slowly, but I am not sure how wide spread they are. I still think most applications are reluctant to create .ZIP files using bzip compression because it is not widely supported (Chicken & Egg ...). This is a website of an application which can create bzip2 compressed zip files. Since it is also in the PkWare format spec, I would imagine that their commercial applications/libraries already do or will shortly create these too. I think that Winzip can also decompress this type of .ZIP file but am not positive about that. http://www.4zip.com/ Cheers, Russ |
From: Guido D. <gui...@gm...> - 2004-03-07 21:34:06
|
Russell Francis wrote: > Hello, > > I am looking at this library and considering using it for an application > I am writing. It seems that zziplib only supports decompression with > zlib. Are there any plans to support other decompression schemes in the > future? > > If support for other methods [12 - bzip2, 6 - exploding) in particular > was submitted would you be inclined to include it with the library? > The general "zip" tools will only produce *.zip files with compression type 0 or 8 (i.e. stored or (zlib) deflated). The usage of explode is long gone, the usage of bzip2 is not known to me. However, I gather that bzip2 support would be interesting for quite a few people. Do you know a compressor utility program that can make use libbzip2 ? cheers, -- guido http://google.de/search?q=guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(+-) r+@>+++ y++ 5++X- (geekcode) |
From: Russell F. <rf3...@oh...> - 2004-03-07 17:43:09
|
Hello, I am looking at this library and considering using it for an application I am writing. It seems that zziplib only supports decompression with zlib. Are there any plans to support other decompression schemes in the future? If support for other methods [12 - bzip2, 6 - exploding) in particular was submitted would you be inclined to include it with the library? I am not subscribed so please CC me. Thanks, Russ |
From: rick p. <ric...@ho...> - 2003-11-25 05:43:53
|
Hi, I've been trying to get zziplib built statically to php-4.3.3. So far all I can get is the shared lib verssion. Here's what i've used to compile zziplib ./configure --with-php=../dir_to_php-4.3.3 --enable-static make make install Then I do the following to config and make php. ./configure --with-apache=../dir_to_apache --with-zip=../dir_to_zziplib --enable-static=zip Please let me know, either way, if you have any insight on how to accomplish this task. I've done a lot of searching around and am not having any luck. Thanks, RIck Philbrick _ ___ ( ` ) _ ( SEATTLE ) (_ ___ (_ _ _) _) / / / / / / / / / / / / / / / / / / / / / / / / _________________________________________________________________ From the hottest toys to tips on keeping fit this winter, youll find a range of helpful holiday info here. http://special.msn.com/network/happyholidays.armx |
From: Guido D. <gui...@gm...> - 2003-06-26 23:04:50
|
The malloc/free in zzip_seek look perfectly paired, it would be really nice to have such a memory leak get ironed out, it's just that I can not see it just so. As for your code about fgets, uhhhm, this is rather straightforward, and with a few strings attached: (a) the zzip_seek function is complex for compressed files, if it happens to be a position _after_ the current, then we start decompressing enough bytes until our internal "byte counter" says that we are there - this is most probably a few bytes less in actual disk space and the seek of the real file descriptor, in fact, huffman encoding needs a diskwise seek-setting being bitwise instead of bytewise. On the other hand, if the seek position of a compressed file is _before_ the current one, then we have no other choice than doing a seek to the physical start of the compressed file, and to start decompressing until the internal "byte counter" says we are there. Now, look at your code for fgets(): you carve a block of bytes from the (zlib-compressed) file, check out the end-of-file position, and finally _seek() the stream to that position - which is _always_ earlier on the disk than the last byte of the memory block to been read just a few moments ago. So, in reality, the zziplib will spring back to the start of the compressed bytestream of your file, and start decompressing until the internal seek-counter points to the end-of-file that was just recognized. And it'll do it on (almost) every zzip_fgets() call. (b) All that is not problematic if the file happens to be actually not compressed, or among the variant of "magic support" where the ZZIP_FILE actually wraps a real (non-archived) file in filesystem of the operating system. That can be checked of course. In effect, the implementation needs a lil' more magic: if the file is a real one, go and do the fgets algorithm, probably the way as shown. But if the file is a compressed one, then better read byte per byte, and stop reading when a '\n' is seen, to avoid to trigger seek at all. While we are in this area of C stdio wrappers, what about that fgetc and it being used to implement the byte-per-byte reading of the (compressed) input file? I am a bit busy with other stuff, PAMHO, I can not check all too deeply into the matters associated with it. Your work is well respected, and still I can not copy the code as it is now. good luck, -- guido > > > ------------------------------------------------------------------------ > > Betreff: > [Zziplib-project] zzip_fgets implementation > Von: > "Kriengkrai J." <kk...@ma...> > Datum: > Tue, 24 Jun 2003 11:41:09 +0700 > An: > zzi...@li... > > > Dear zziplib developer, > > First of all, thank you for developing zziplib. :-) > > I've tried to implement zzip_fgets (using zziplib version 0.10.81) but it turn out that there's memory leak (perhaps in zzip_seek). > > Source's here : > -- > char *zzip_fgets(unsigned char *s, unsigned n, ZZIP_FILE *f) > { > unsigned int i, no; > > if ((no = zzip_fread(s, sizeof(char), n-1, f))) { > s[no] = '\0'; > for (i=0;i<no;i++) { > if (s[i]=='\n') { > s[i+1]='\0'; > break; > } > else if (s[i]=='\0') break; > } > zzip_seek(f, i-no+1, SEEK_CUR); > return s; > } > else return 0; > } > -- > > Please advise. Thank you. > Yours, > -kk- |
From: Kriengkrai J. <kk...@ma...> - 2003-06-24 04:41:18
|
Dear zziplib developer, First of all, thank you for developing zziplib. :-) I've tried to implement zzip_fgets (using zziplib version 0.10.81) but it turn out that there's memory leak (perhaps in zzip_seek). Source's here : -- char *zzip_fgets(unsigned char *s, unsigned n, ZZIP_FILE *f) { unsigned int i, no; if ((no = zzip_fread(s, sizeof(char), n-1, f))) { s[no] = '\0'; for (i=0;i<no;i++) { if (s[i]=='\n') { s[i+1]='\0'; break; } else if (s[i]=='\0') break; } zzip_seek(f, i-no+1, SEEK_CUR); return s; } else return 0; } -- Please advise. Thank you. Yours, -kk- -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup CareerBuilder.com has over 400,000 jobs. Be smarter about your job search http://corp.mail.com/careers |