cocos2d :: ZipFile :: createWithBuffer does not work properly

• cocos2d-x version:3.17.2 ( [3f26b75])
• devices test on: iPhone and Android
• developing environments
  • NDK version: r16b
  • Xcode version: 11.0 and 10.3

std::string fullpath = cocos2d::FileUtils::getInstance()->fullPathForFilename(filepath);
Data zipdata;
cocos2d::FileUtils::getInstance()->getContents(fullpath,&zipdata);
cocos2d::ZipFile* zipfile = cocos2d::ZipFile::createWithBuffer(zipdata.getBytes(), zipdata.getSize());
for( std::string filename = zipfile->getFirstFilename(); !filename.empty(); filename = zipfile->getNextFilename() ){
.......
}

The zipfile is in an incorrect state.

[halx99]

I will check later.

[minggo]

Yep, it may be caused by updating unzip lib.

[halx99]

I submit a fix PR of minizip: cocos2d/cocos2d-x-3rd-party-libs-bin#379

[halx99]

@minggo please review & merge it.

[minggo]

It is merged, please update to v3-deps-167.

[halx99]

But, I think maybe modify cocos sources is better than modify minizip sources. and I realize that, the original minizip no unzOpenBuffer API.
see: https://github.com/nmoinvaz/minizip/blob/1.2/unzip.h

[halx99]

@minggo The follow code maybe better, and the minizip sources can revert to same with: https://github.com/nmoinvaz/minizip/tree/1.2

bool ZipFile::initWithBuffer(const void *buffer, uLong size)
{
    if (!buffer || size == 0) return false;

    zlib_filefunc_def memory_file = { 0 };
    
    std::unique_ptr<ourmemory_t> memfs(new(std::nothrow) ourmemory_t{ (char*)const_cast<void*>(buffer), static_cast<uint32_t>(size), 0, 0, 0 });
    if (!memfs) return false;
    fill_memory_filefunc(&memory_file, memfs.get());
    
    _data->zipFile = unzOpen2(nullptr, &memory_file);
    if (!_data->zipFile) return false;
    _data->memfs = std::move(memfs);

    setFilter(emptyFilename);
    return true;
}

[halx99]

@minggo I submit a new PR: #20192, now engine can works well with out any API or implementation changes of minizip-1.2.0

[minggo]

Yep, it is better to modify in engine.

[halx99]

@waochi Please pull the latest sources to check whether this issue has been fixed.