Skip to content

OCIOArchive unit test failing on minizip-bng 4.0.10 #2157

@remia

Description

@remia

While building OCIO with the dependencies from up to date brew, I'm noticing new unit test failures related to OCIOArchive, specifically when extracting the Windows test archive.

FAILED: exception thrown from procConfigFromExtractedArchive = configFromExtractedArchive->getProcessor( "plain_lut1_cs", "shot1_lut1_cs" ): "The specified file reference 'shot1/lut1.clf' could not be located. The following attempts were made: '/tmp/OCIOTestTemp_context_test1/shot4/shot1/lut1.clf' : '/tmp/OCIOTestTemp_context_test1/shot1/shot1/lut1.clf' : '/tmp/OCIOTestTemp_context_test1/shot2/shot1/lut1.clf' : '/tmp/OCIOTestTemp_context_test1/shot3/shot1/lut1.clf' : '/tmp/OCIOTestTemp_context_test1/shot3/subdir/shot1/lut1.clf' : '/tmp/OCIOTestTemp_context_test1/shot1/lut1.clf'."

My understanding is that with this new minizip-ng version, backward compatibility with archives made from Windows with minzip version less than 3.0.7 is no longer maintained. Starting from 3.0.7, Windows backslash path separators are converted to forward (zlib-ng/minizip-ng#644) and since version 4.0.10, the extracting code no longer consider backslash as a folder separator by default on Unix (zlib-ng/minizip-ng#834). In the unit test failure, I can indeed see that we have files containing backslashes in their names being extracted, instead of producing folders, like macOS unzipper do from the Finder.app for example.

Simple fix would be to update our test Windows archive I guess, I'm not sure if people have been making .ocioz archive from Windows but these might eventually break in the current state of things.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions