Opened 22 months ago

Closed 22 months ago

Last modified 22 months ago

#13866 closed bug (fixed)

unzip can't set directory attributes

Reported by: Pete Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: - General Version: R1/Development
Keywords: unzip Cc:
Blocked By: Blocking: #13899
Has a Patch: no Platform: All

Description

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")

Attachments (2)

dummy.zip (2.5 KB ) - added by Pete 22 months ago.
short zip file that (sometimes) shows directory attribute problem
unzip_terminal.log (1.6 KB ) - added by vidrep 22 months ago.

Download all attachments as: .zip

Change History (20)

comment:1 by diver, 22 months ago

Blocking: 13899 added

comment:2 by mmlr, 22 months ago

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

by Pete, 22 months ago

Attachment: dummy.zip added

short zip file that (sometimes) shows directory attribute problem

comment:3 by Pete, 22 months ago

Has a Patch: set

comment:4 by Pete, 22 months ago

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.

comment:5 by Pete, 22 months ago

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!!

comment:6 by pulkomandy, 22 months ago

Has a Patch: unset

comment:7 by AGMS, 22 months ago

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?

comment:8 by AGMS, 22 months ago

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.

comment:9 by pulkomandy, 22 months ago

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.

comment:11 by AGMS, 22 months ago

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...

comment:12 by pulkomandy, 22 months ago

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).

comment:13 by AGMS, 22 months ago

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 :-).

comment:14 by pulkomandy, 22 months ago

Resolution: fixed
Status: newclosed

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.

comment:15 by vidrep, 22 months ago

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

by vidrep, 22 months ago

Attachment: unzip_terminal.log added

comment:16 by AGMS, 22 months ago

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

comment:17 by GregCrain, 22 months ago

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.

Last edited 22 months ago by GregCrain (previous) (diff)

comment:18 by waddlesplash, 22 months ago

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

Note: See TracTickets for help on using tickets.