ZipFile class with zlib compressed file

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 18/10/2006 at 06:42, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   9.521
Platform:      Mac OSX ;
Language(s) :     C++ ;

---------
Can the ZipFile class be used on purely zlib compressed files or does it only support zip archives?

This is being asked since I've been battling with an impossible-to-solve problem with my own static zlib for XCode. Memory compression/decompression with this works. Using gz...() calls always return with an error (and this is XCode (darned, sucky XCode!) - my zlib static libraries have never ever failed with VC++6, VS2005, and CW).

Since I've tired of this battle (and can find absolutely nothing online to assist), the ZipFile class looks like a workable alternative (next to last alternative - the last is to load the entire file into memory and decompress there - not a good alternative imho).

Thank you very much,

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 18/10/2006 at 12:14, xxxxxxxx wrote:

Hmmm... The ZipFile class doesn't seem to be working with zlib compressed files. But I tried this and it doesn't work either. Can you provide an example for this situation?

// Decompress infile into outfile, return outfile  
//*---------------------------------------------------------------------------*  
Bool myZLib::DecompressFile(Filename inname, Filename outname)  
//*---------------------------------------------------------------------------*  
{  
     AutoAlloc<BaseFile>     infile;  
     if (!infile)     { GePrint("Error: infile"); return FALSE; }  
     AutoAlloc<BaseFile>     outfile;  
     if (!outfile)     { GePrint("Error: outfile"); return FALSE; }  
  
     if (!infile->Open(inname, GE_READ, FILE_IGNOREOPEN, GE_INTEL))          { GePrint("Error: infile->Open"); return FALSE; }  
     if (!outfile->Open(outname, GE_WRITE, FILE_IGNOREOPEN, GE_INTEL))     { GePrint("Error: outfile->Open"); return FALSE; }  
     LONG     inlen =          infile->GetLength();  
     LONG     outlen =     inlen * 16;  
     if (!inlen)               { GePrint("Error: empty file"); return FALSE; }  
     CHAR*     inbuf =          (CHAR* )GeAlloc(inlen+outlen);  
     CHAR*     outbuf =     inbuf+inlen;  
     inlen =                    infile->ReadBytes(inbuf, inlen);  
     if (inlen)  
     {  
          GePrint("inlen = "+LongToString(inlen));  
          if (UncompressDataRaw(inbuf, inlen, outbuf, &outlen;))  
          {  
               if (outlen)  
               {  
                    if (outfile->WriteBytes(outbuf, outlen))  
                    {  
                         GeFree(inbuf);  
                         return TRUE;  
                    }  
                    else     GePrint("Error: outfile->WriteBytes");  
               }  
               else     GePrint("Error: Uncompress Bytes");  
          }  
          else     GePrint("Error: Uncompresss");  
     }  
     else     GePrint("Error: ReadBytes");  
     GeFree(inbuf);  
     return FALSE;  
}

This always fails at UncompressDataRaw(). Note that the code is using an exaggerated decompression buffer (16 times the compressed size - same result at 32).

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/10/2006 at 02:01, xxxxxxxx wrote:

Ah, I see. The CompressDataRaw() and UncompressDataRaw() work much the same as zlib's standard memory compression-decompresssion. You need to have the original uncompressed size to start with. Of course this won't work with a zlib compressed file as I don't know what size it 'was' when uncompressed. Argh...

Will try ZipFile one more time before surrendering back to determining why libz.dylib and myzlib.a won't let me do anything with files (gzopen() returns with a Z_STREAM_ERROR?).

Thanks,

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/10/2006 at 05:49, xxxxxxxx wrote:

One simple question: Will the ZipFile class work with zlib compressed files?

So far, it appears not (Open always fails).

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/10/2006 at 06:08, xxxxxxxx wrote:

Quote: One simple question: Will the ZipFile class work with zlib compressed files?
>
> * * *
>
> * * *

I don't know. I have to ask the developers.

cheers,
Matthias

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/10/2006 at 06:35, xxxxxxxx wrote:

Thank you, Matthias! I appreciate your effort.

Even with the libz.dylib, still getting the Z_STREAM_ERROR on gzopen(). This only occurs with the XCode UB version (not on the PPC, Windows, and Win64 versions). Realizing this is 'beyond the scope' of the SDK, don't know if this is caused by the SDK, the XCode project settings, or some nuance related to MacOS X (?). I'm looking for answers at the CocoaBuilder.com archives without too much luck. This is extremely frustrating...

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/10/2006 at 08:36, xxxxxxxx wrote:

Hmmm. Since I cannot find a single reference to any problem with XCode/UB/zlib and gzopen, this must be related to the SDK. I've replaced my static 'myzlib.a' with the libz.dylib (therefore I am completely compliant with XCode) and still the same situation exists. Since noone anywhere on the planet has mentioned such a problem, there must be something in the SDK project settings or the api_lib itself causing this (remember that it works on three other compilers and countless versions of two plugins before challenging my source code).

I've removed the old zlib headers from my project and folders so that the 'system' ones are used. I've tried changing the path string for gzopen() from ':' separators to '/' separators. gzopen() continues to fail. From what I've read, there is no need of Zlib.framework since an earlier version of XCode. I've tried Zero-link on (reset to off after no progress). The file path is absolute and checks out. The problem is beyond my control - it is either system related or xcode related.

Help.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/10/2006 at 13:19, xxxxxxxx wrote:

Update:

Okay, for the sake of my sanity, I've constructed a 'bare-bones' plugin to test this. It is comprised of a CommandData with a GeDialog. The GeDialog has a button which opens a file dialog so that I can select a zlib-compressed file. Then the decompression is performed.

Same error. Now I'm 99% positive that this is related to the SDK (or some facet thereof). So, the ball is in your court. I'll provide this (simple) plugin code if you need to verify or want to prove me wrong.

Thanks,

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/10/2006 at 13:54, xxxxxxxx wrote:

I should ask where I can upload the archive for this code for your testing. It includes a 'test' zlib compressed file (12MB), an XCode project, and a VC6 project with the static zlib used there (to show that it works someplace else - tested to my satisfaction). Most likely, you'll have to repoint the api libs (I've just included all of the targets for the copied project, using R9.6 as default in VC6). Note that the zlib headers are included for the VC6 project, but are not needed for the XCode project (as they come from the usr/include folder).

Appreciate anything that you can deduce!

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 20/10/2006 at 12:06, xxxxxxxx wrote:

Now that I've established that this isn't exactly a zlib problem, but more of a problem with using POSIX/HSF file paths in XCode (fopen, gzopen, et al suffer here), now the focus of the problem is this:

The suggested solution (besides not using fopen - impossible for gzopen) is to get an FSRef for the file and convert to a path string using FSRefMakePath() and use that in fopen() et al. This would be great, but I'm in an SDK and the file is returned using the SDK Filename class (FileSelect) - which will only allow opening with BaseFile/HyperFile or getting a string - exactly what's causing the problem in the first place (arghh!).

When using a POSIX representation, one solution is to prepend the full path with "/Volumes/", but this creates a file whose name is the path - not very useful. Plus, it has been stated that such a workaround is not guaranteed to work in all situations. So far, HSF full file paths are what I've been using and they haven't worked either.

The other solution is to use relative paths but set the 'current working directory' beforehand. I can't find an example of how I would do this since the files are not relative to the plugin per se (they can be anywhere - other drives, external drives, CD, DVD, network, etc.).

The phrase "Catch 22" comes to mind.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 20/10/2006 at 17:02, xxxxxxxx wrote:

Okay. It appears that the '/Volumes/" solution is the best bet - as it works! There are caveats to using it, but there is one last option if that fails - load the file into memory and decompress it there. Hopefully, the pre-known decompressed size will not interfere using the direct zlib memory decompression methods.