maennchen/ZipStream-PHP

Fix MacOs Tests

maennchen opened this issue · 13 comments

Description of the problem

Currently the MacOS tests hang forever in the CI. THis has to be solved to be able to run the CI.

  • Fix Test
  • Re-Enable Test in Workflow
  • Require test to pass before merging in the repository settings

I do not have a MacOS device. Therefore I can't fix this one. If anyone is interested to make sure this lib is MacOS compatible, please have a look at this issue.

i want to help out, what is needed here? make the unit tests work on osx?

@pieterdt that would be awesome 🙂

is it the intention to run the test with the archive utility? because the command line can zip/unzip as well with the regular commands. Of course, chances are very high that a mac user will (unknowingly) trigger the archive utility, but if they have configured another tool as the default, that will be used.

Has the test worked in the past? because the archive utility is not scriptable, so not suited to be called on the command line.

@pieterdt The idea was to use the archive utility. The reason for that is that it is the standard tool people use.

I think I was able to use the archive utility via cli at some point. No idea is that still works.

It should probably be possible to use the open cmd on OSX to trigger it and just sleep for a bit in PHP before checking if it did it properly.

@pieterdt Apparently the Archive Utility use a tool called ditto internally. One could try if ditto also produces problems with known broken zips to verify that.

Can ditto open the file mentioned here? #49 (comment)

ditto could open zip files I created with Archive utility, but it failed on a bunch of zipfiles I created with Zipstream.
In that case the error is
ditto: Couldn't read pkzip signature. ditto: Not a central directory signature

The file from isue 49 resulted also in an error:
ditto: file1.txt: No such file or directory ditto: Couldn't read pkzip signature.

But it could be opened by the Archive utility.

Opening test.zip with vi also resulted in a bit of error reporting when navigating to file1.txt. So I think it is corrupt, but Archive utility could recover it. Ditto not.

Test was removed in #203

Extracted into #230