ZipArchive::close: zip_close called before saving buffer data.

[Trico-Everfire]

int result = zip_close(zipHandle); 

is called before :

int srcOpen = zip_source_open(zipSource);

causing zipSource to be empty and error. The responding error:

Helper::callErrorHandlingCallback(zipHandle, "can't read back from source: changes were not pushed in the buffer\n", errorHandlingCallback);

segfaults.

using vcpkg libzippp.

[Trico-Everfire]

moving it to below does indeed fix the issue, but another arises where close() does not update the buffer because of an issue with zip_source_read always returning 0 even when the buffer has been altered. Also, ::New segfaults outright.

[ctabin]

Hi @Trico-Everfire,
Can you give the code location you're looking at ? Also, do you have a test case ?

[Trico-Everfire]

Hi @Trico-Everfire, Can you give the code location you're looking at ? Also, do you have a test case ?

https://github.com/ctabin/libzippp/blob/master/src/libzippp.cpp#L393-L443

[Trico-Everfire]

The test case is the example code you provide in the readme.

[elliopitas]

same problem using similar to readme code

string path="some valid path";
const unsigned int folderSize=privateFunctions::dirSize(path);
void* buffer = calloc(folderSize, sizeof(char));
libzippp::ZipArchive* zip=libzippp::ZipArchive::fromWritableBuffer(&buffer, folderSize, libzippp::ZipArchive::New);
zip->addEntry(path);
zip->close(); //segfaults here
libzippp::ZipArchive::free(zip);
free(buffer);

[Trico-Everfire]

It's the same for everyone as zip->close() is crucial to the saving process, it will always crash in all use cases. I would go about fixing it myself, and the base problem is pretty fixable, the rest of the problem regarding the second problem I had with this leads all the way into zlib, so for the sake of my own sanity I wrote my own zip library that does not handle compression, just opening a zip and saving it to a buffer.

[ctabin]

Thanks for the feedback, I'll take a look at it asap. In the meantime, a PR is always welcome.

[flomnes]

It seems that ~ZipArchive calls close once again, which doesn't seem to be supported.