PureZIP library : ZIP / UNZIP files

[jamba]

hi

is there something I am doing wrong here?
I am getting an IMA on the ProcedureReturn (or endprocedure, if I take out the return).

the debug output works normally.
what could it be that is happening?

(I am using PB 4.5b4, win7, x86, PureZip DLL)

I created the file with PureZIPDLL_AddFiles, could this be a cause? but the archive can be read. I can even open it with 7zip and it looks fine.

If I enable the purifier...it all works fine with no errors. no purifier and I get the IMA.

Code: Select all

XIncludeFile "PureZIP_DLL_2_INCLUDE.pb"
  ;open existing
Define MyZIP.s = "C:\" + "test.zip"

Procedure.i GetZIPinfo(zipPath.s) ;This requires the PureZIP userlib
  ;Returns array of the filenames contained in zip archive  
  Protected myFileInfo.PureZIP_FileInfo
  Protected r.l, count.l
  
  If PureZIPDLL_Archive_Read(zipPath)
    r = PureZIPDLL_Archive_FindFirst()
    count = 0
    While r = #UNZ_OK 
      PureZIPDLL_Archive_FileInfo(@myFileinfo)
      Debug "Filename: " + myFileinfo\FileName
      Debug "Comp Size: " + Str(myFileinfo\CompressedSize)
      Debug "UnComp Size: " + Str(myFileinfo\unCompressedSize)
      r = PureZIPDLL_Archive_FindNext()
      count + 1
    Wend
    PureZIPDLL_Archive_Close()
  EndIf
  ProcedureReturn 1   ;<---------- Error occurs here
EndProcedure

Debug GetZIPinfo(myZIP)

debug output:

Code: Select all

Filename: image0.png
Comp Size: 18858
UnComp Size: 25222
Filename: image1.png
Comp Size: 22287
UnComp Size: 24921
Filename: image2.png
Comp Size: 24254
UnComp Size: 26375
Filename: image0.bmp
Comp Size: 26241
UnComp Size: 30054
Filename: image1.bmp
Comp Size: 23821
UnComp Size: 30054
Filename: image2.bmp
Comp Size: 26060
UnComp Size: 30054

also, not looping produces the same error.

Code: Select all

XIncludeFile "PureZIP_DLL_2_INCLUDE.pb"
  ;open existing
Define MyZIP.s = "C:\" + "test.zip"

Procedure.i GetZIPinfo(zipPath.s) ;This requires the PureZIP userlib
  ;Returns array of the filenames contained in zip archive  
  Protected myFileInfo.PureZIP_FileInfo
  Protected r.l, count.l
  
  If PureZIPDLL_Archive_Read(zipPath)
    r = PureZIPDLL_Archive_FindFirst()
    count = 0
    While r = #UNZ_OK 
      PureZIPDLL_Archive_FileInfo(@myFileinfo)
      Debug "Filename: " + myFileinfo\FileName
      Debug "Comp Size: " + Str(myFileinfo\CompressedSize)
      Debug "UnComp Size: " + Str(myFileinfo\unCompressedSize)
      
      Break
      
      r = PureZIPDLL_Archive_FindNext()
      count + 1
      
    Wend
    PureZIPDLL_Archive_Close()
  EndIf
  ProcedureReturn 1          ;<---- error still occurs here
EndProcedure

Debug GetZIPinfo(myZIP)

[jamba]

with the same code above using the UserLib instead of the DLL, there is no issue.

[gnozal]

with the same code above using the UserLib instead of the DLL, there is no issue.

I tried your code and no crash problem.
Could you try another ZIP file, and if it works, post the code you used to create the zip file ?

[DoubleDutch]

I can create a crash with 'add files' with this code:

Code: Select all

myzip$="Elementary Reports.u3p"

If PureZIP_Archive_Create(myzip$,#APPEND_STATUS_CREATE)
  PureZIP_Archive_Close()
  PureZIP_AddFiles(myzip$,"manifest\*.*",#PureZIP_StorePathAbsolute,#PureZIP_RecursiveZeroDirs)    ; <--- IMA here  (write error at address 0, with purifier it's address 4!!!)
EndIf

Here is all the code and data in a zip:
http://elementaryreports.com/downloads/zipbug.zip

[gnozal]

I have recompiled PureZIP with PB4.50 RC1.
This seems to fix the problem.

Download : http://gnozal.ucoz.com/PureZIP_450.zip

[DoubleDutch]

It does. Thanks.

Are you doing the same to your other libs, should I re-download those too?

[gnozal]

Are you doing the same to your other libs, should I re-download those too?

No.
Unless there is some issue, I will only recompile the libraries for PB4.50 final.
Note that PureCOLOR, PureLVSORT and PureRESIZE (libraries with gadget functions) were recompiled with PB 4.50 RC.

[akee]

Code: Select all

a$ = "C:\TEMP\TEST.zip"
m$ = "C:\TEMP\*.txt"
Debug PureZIP_AddFiles(a$, m$, #PureZIP_DontStorePath, #PureZIP_NotRecursive)

Is there a workaround for unicode compiled .EXE?

[gnozal]

Code: Select all

a$ = "C:\TEMP\TEST.zip"
m$ = "C:\TEMP\*.txt"
Debug PureZIP_AddFiles(a$, m$, #PureZIP_DontStorePath, #PureZIP_NotRecursive)

Is there a workaround for unicode compiled .EXE?

What do you mean ?
Seems to work fine here.

Note : the ZIP standard doesn't support unicode files names. Some newer archivers (like Pkzip 4.5+ / Winzip 11.2+) store unicode names using the UTF-8 standard. This method isn't compatible with older ZIP packers. Others store Unicode names in an extra field (like the Info-Zip method). But there is no real standard. If you need real unicode support, better use RAR or 7-ZIP.

[akee]

Ya! When I check unicode and compile. I get 0 files and no .zip file created.
When I uncheck unicode, I get the .zip file created and 2 files.

I'm using PB 4.51 and PureZip 4.50.

[gnozal]

Ya! When I check unicode and compile. I get 0 files and no .zip file created.
When I uncheck unicode, I get the .zip file created and 2 files.
I'm using PB 4.51 and PureZip 4.50.

Like I said, no problem here. I get the same results, with or without unicode checked.
Maybe it's an issue with the file names / codepage ; what do they look like ?

Does it work using the PureZIP_Archive_*() functions ?

[akee]

Using the code below...

Code: Select all

a$ = "C:\TEMP\TEST.zip"
m$ = "C:\TEMP\*.txt"
Debug PureZIP_AddFiles(a$, m$, #PureZIP_DontStorePath, #PureZIP_NotRecursive)

In Compiler Options, with "Create unicode executable" checked, when I click Compile/Run, I get Debug output 0 and no .zip file.
If "Create unicode executable" unchecked, when I click Compile/Run, I get Debug output 2 and TEST.zip file created. (correct situation)

My situation is I need the unicode executable checked or else my program won't work in Chinese and I also need Zip files in and archive.
My question is... is there a work around to pass the parameters to PureZip_AddFiles with the executable compiled in unicode?
Sorry for the trouble. I'm just dependant on PureZip and my client needs their backup in .ZIP format and in Chinese.

[gnozal]

My situation is I need the unicode executable checked or else my program won't work in Chinese and I also need Zip files in and archive.
My question is... is there a work around to pass the parameters to PureZip_AddFiles with the executable compiled in unicode?
Sorry for the trouble. I'm just dependant on PureZip and my client needs their backup in .ZIP format and in Chinese.

Sorry akee,
there is no workaround.

That said, I don't know what the issue may be, as it works fine here with unicode checked, although I can't test Chinese file names.

I created a file named '确证阳性标本长短孵育结果对比.txt', it looks like '||||||||||||||||.txt' in my explorer.
However, PureZIP finds and compresses this file : but the stored filename is like '______________.txt' as the ZIP format doesn't support unicode names.

[akee]

Ok! Thanks gnozal...

I checked the string size using StringByteLength(). Compiling with Unicode produces a string twice the size.
Guess to fix my question is to find a way to convert unicode string to ascii string.

[Starwolf20]

Hi Gnozal

The 1er post says that PureZip uses Zlib V1.23.
The ZLIB website says that the last version is V1.25. Is an update of PureZip planned ?
Thanks
---------------------------------------------------------------------------------------------------------------------------------------------
Current release:
zlib 1.2.5
April 19, 2010

Version 1.2.5 fixes bugs in gzseek() and gzeof() that were present in version 1.2.4 (March 2010). All users are encouraged to upgrade immediately.

Version 1.2.4 has many changes over 1.2.3, including these improvements:
* Fixed bugs in adler32_combine(), compressBound(), and deflateBound()
* Wholesale replacement of gz* functions with faster versions
* As part of that, added gzbuffer(), gzoffset(), gzclose_r(), and gzclose_w() functions
* Faster Z_HUFFMAN_ONLY and Z_RLE compression for images and other specialized compression
* Added flush options Z_BLOCK to deflate() and Z_TREES to inflate() for finer control
* Added inflateReset2() and inflateMark() functions, the latter to aid in random access applications
* Added LFS (Large File Summit) support for 64-bit file offsets and many other portability improvements
* Updated examples in examples/ and updated third-party contributions in contrib/ [/i]