Bug in juce_ZipFile?


#1

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)
}

#2

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!


#3

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


#4

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


#5

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?


#6

Try the modules branch, not the master branch.


#7

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


#8

No, you need to use GIT.


#9

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?


#10

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.


#11

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.


#12

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


#13

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.


#14

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


#15

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.


#16

Ah, I see, thanks!


#17

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)