Bug in juce_ZipFile?

I think I found a bug in ZipFile::uncompressEntry( ) in the latest tip snapshot. If one of your zip entries is a directory you enter this block in ZipFile::uncompressEntry( )

if (zei->entry.filename.endsWithChar ('/'))
{
     targetFile.createDirectory(); // (entry is a directory, not a file)
}

After creating the directory you fall through to the end of the function and return false. This causes you to break out of the loop in ZipFile::uncompressTo( ), and no further entries are uncompressed. To get the behavior I had in previous revisions of the tip, I simply modified the line in ZipFile::uncompressEntry( ) to be:

if (zei->entry.filename.endsWithChar ('/'))
{
     return targetFile.createDirectory(); // (entry is a directory, not a file)
}

Ah, thanks very much - yes, I think I must have meant to do the return there like you suggested! Will get that tidied up right away!

I’m facing a problem when I try to zip more than one file. The resulting archive becomes unreadable. Here’s my code:

// create archive
	File tempFolder(getCurrentGroovesTempFolder(false));
	ZipFile::Builder builder;
	Array<File> grooveFiles;
	tempFolder.findChildFiles(grooveFiles, File::findFiles, false);
	for (int i = 0; i < grooveFiles.size(); i++) { 
		builder.addFile(grooveFiles[i], 0, grooveFiles[i].getFileName());
	} 
	File outputFile(newFilePath);
	FileOutputStream os(outputFile);
	builder.writeToStream(os);

Am I missing something? The problem happens when there is more than one file in the temp folder. I checked the files individually and they are fine. They can actually be zipped separately, but not together.

Thanks for any help.

Mariano

I seem to remember fixing something in the zip file code recently - maybe try the latest modules branch if you haven’t already…

Yes, I got the latest version (1.54), and the only change on the juce_ZipFile.cpp was a casting to int of compressedData.getDataSize()

But even that didn’t solve the problem. Has anybody been able to zip more than one file?

Try the modules branch, not the master branch.

I did an update from the introjucer. Is there any setting to define there for targetting a different branch?

No, you need to use GIT.

Oh, I see… Just got the latest modules and it seems there are indeed serious changes in the ZipFile class.

My project was started by deriving the existing plugin demo, so I didn’t go through the introjucer. How do you suggest I proceed to migrate to the new files with minimum effort?

It’s up to you, really… The modules branch will become the next release, so you could either migrate now, or just copy the changes from the zip file class and use that temporarily.

Ok, I migrated to the latest version of the library (created a new plugin with introjucer, then migrated my code), but the zipping of multiple files still doesn’t work. It would help if I could have confirmation that anyone else has been able to do that.

I also found an issue with the way the jucer creates viewports. It creates the instructions in this order:

addAndMakeVisible (strokesViewport = new Viewport (L"strokesViewport")); strokesViewport->setScrollBarsShown (false, false); strokesViewport->setViewedComponent (new SGLoopEditorStrokes (this));

But setScrollBarsShown() triggers an updateVisibleArea that fails because the viewed component is not yet set. Moving setScrollBarsShown() under setViewedComponent() solves the problem.

I use the zipfile class to create the zipped juce module files that the introjucer uses, so yes, it definitely works for me.

Just ignore the first part of my mail. It does work. I was trying to open it as a .zip file, when it was a .gz. Wonderful!

The second part about viewports in jucer still stands, though. But I can correct it manually.

When you say that updateVisibleArea fails, what do you mean? Asserts? Crashes?

It’s an assert at:

Point<int> Viewport::viewportPosToCompPos (const Point<int>& pos) const { jassert (contentComp != nullptr); return Point<int> (jmax (jmin (0, contentHolder.getWidth() - contentComp->getWidth()), jmin (0, -pos.getX())), jmax (jmin (0, contentHolder.getHeight() - contentComp->getHeight()), jmin (0, -pos.getY()))); }

I think checking in updateVisibleArea whether the view component is set should solve the problem.

Ah, I see, thanks!

Hi,

I just had some trouble using the Juce::ZipFile class.
basically, I’m doing an export/import functionnality:
export, zip_builder.AddFiles(original file, compression level, path in archive) and write to a File stream
import,
I create a ZipFile with the archive path. And i browse the entries.

BUT it seem that the entries header buffer change depending on the compression level.
(for instance, if compression level is 0 the filename of the entry is the one I setted, if compression level == 2, I can find the filename in the buffer but with extra data before, if the compression level is 9, I cant find it anymore)
I 'm not sure, but it is impossible to open the zip file with winrar or gzip if compression level is != 0.
Also with level compression at 0, I’ve got the error “unexpected end of archive”, with winRAR 32 on Seven 64
So there is probably something over there happening.

Is it a known bug ?
If yes, where can I get the fix ?

Thanks

NB (I’m currently running with 1.53 release version)