unzip can't set directory attributes

[Pete]

In the latest hrevs (I have hrev51670) when unzip finds a directory in a zipfile that it has to create, it throws an error: "Error writing file attributes." This didn't happen in my older system (hrev50180).

To demonstrate, create a folder with Tracker -- "DUMMY", say -- and put another "SUBDUMMY" within it. Zip it up, and then unzip it:

> zip -r dummy.zip DUMMY
  adding: DUMMY/ (stored 0%)
  adding: DUMMY/SUBDUMMY/ (stored 0%)
> rm -r DUMMY
> unzip dummy.zip
Archive:  dummy.zip
   creating: DUMMY/
Error writing file attributes.
   creating: DUMMY/SUBDUMMY/
Error writing file attributes.
> 

If you use Expander, it will pause with an alert each time; it will continue, but it's annoying...

I'd assume this is an OS problem, rather than unzip itself, as the latter probably hasn't changed much. (Sorry -- not sure what heading this comes under, so I've left it "General")

[mmlr]

I am unable to reproduce this on x86_64. Can you attach a example zip file that exhibits the problem?

[Pete]

short zip file that (sometimes) shows directory attribute problem

[Pete]

Things are more arbitrary than I first reported, it seems. (I'm using gcc2 hybrid) A given zip file may bring up the error alert on one occasion, and not on another! I can't find any determining condition. In no case, though, are the directory attributes actually written, and if you unzip from a Terminal you will always see the errors.

It seems Diver (in the forum) is correct. The unzip app is at fault, not the OS. I copied over an earlier unzip, and it works properly.

I've attached a somewhat arbitrary zipfile than can show the problem. Run it from the Terminal to be sure to see the errors.

[Pete]

OT -- I am no going to submit anything else to Trac unless you can fix the "spam trap" The captchas are quite unreadable -- three attempts this time. And it *always* traps me!!

[AGMS]

Yes, does seem to be the zip program at fault. Works with an older unzip, HaikuPorts version 6.0-2 and internal version:
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler.

While the one in the more recent Haiku (hrev51729) malfunctions and has HaikuPorts version 6.10c11-1 and internal version:
UnZip 6.10c11 BETA of 10 Oct 2014, by Info-ZIP. Maintainer: <Apply Within>

So, punt this to HaikuPorts bug tracker?

[AGMS]

By the way, there's a similar bug at ​https://github.com/haikuports/haikuports/issues/218 from 2015, seem to have fixed it by going back to unzip 6.0.

[pulkomandy]

IIRC we switched unzip to use the standard UNIX makefiles instead of the BeOS ones. It's quite possible that some config option got lost in the process. Yes, please move the issue to haikuports as there is not much we can do from Haiku side for now.

[vidrep]

Here's a link to a zip that exhibits the attributes issue: ​http://pulkomandy.tk/~beosarchive/unsorted/svalka.freenet59.ru/BeOS/Media/MP3/8hz-mp3-src.zip

[AGMS]

I've added a Haiku Ports issue, see ​https://github.com/haikuports/haikuports/issues/2075

Anyone know how to get the build system to use the older recipe that works? There are two recipe files in that project, I assume it picks the one with the higher version number. Maybe a rename would do it...

[pulkomandy]

Someone should mark the new one as "broken" by adding a ! in front of the affected architectures (ARCHITECTURES="!x86_gcc2"). Additionally we should still investigate this and solve the issue before the final 6.10 is released.

We don't want to ship with 6.0 as-is because it has other problems, in particular with handling japanese characters in zipped filenames (not everyone may notice it, but still).

[AGMS]

HaikuPorts has been updated to use the older (mostly) working unzip 6.0. Thanks everyone for the help in fixing this (now I know a bit more about HaikuPorts :-).

[pulkomandy]

I added a recipe for unzip 6.10c23 which includes bugfixes previously made only to the 6.0 branch. It should land soon in the repos.

[vidrep]

unzip 6.10c23 failed building on 64 bit (hrev51736). Haikuports terminal log attached.

[AGMS]

Seems to be building for a PowerPC CPU, probably not what it needs.

[GregCrain]

I've been trying to build x64 on Haiku x64, and it keeps getting stuck on an unzip part of the script. I checked the syslog, and there are endless writes:

KERN: vm_page_fault: thread "unzip" (3501) in team "unzip" (3501) tried to write address 0x7ffa5be47ff8, ip 0x7c62ea38ee ("libroot_build.so_seg0ro" +0x168ee)

I was going to submit another ticket, but I think it is related to this fix. I'm hoping that this update fixes building x64.

[waddlesplash]

@Greg: It won't, the unzip used as part of the build is in the tree in src/bin, this is unrelated to that.