-
Notifications
You must be signed in to change notification settings - Fork 483
Description
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.