Opened 18 months ago

Closed 18 months ago

Last modified 18 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 18 months ago.
short zip file that (sometimes) shows directory attribute problem
unzip_terminal.log (1.6 KB) - added by vidrep 18 months ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 18 months ago by diver

Blocking: 13899 added

comment:2 Changed 18 months ago by mmlr

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

Changed 18 months ago by Pete

Attachment: dummy.zip added

short zip file that (sometimes) shows directory attribute problem

comment:3 Changed 18 months ago by Pete

Has a Patch: set

comment:4 Changed 18 months ago by 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.

comment:5 Changed 18 months ago by 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!!

comment:6 Changed 18 months ago by pulkomandy

Has a Patch: unset

comment:7 Changed 18 months ago by 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?

comment:8 Changed 18 months ago by 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.

comment:9 Changed 18 months ago by 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.

comment:10 Changed 18 months ago by vidrep

comment:11 Changed 18 months ago by 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...

comment:12 Changed 18 months ago by 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).

comment:13 Changed 18 months ago by 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 :-).

comment:14 Changed 18 months ago by pulkomandy

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 Changed 18 months ago by vidrep

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

Changed 18 months ago by vidrep

Attachment: unzip_terminal.log added

comment:16 Changed 18 months ago by AGMS

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

comment:17 Changed 18 months ago by 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.

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

comment:18 Changed 18 months ago by 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.

Note: See TracTickets for help on using tickets.