Opened 3 years ago

Closed 2 years ago

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

Download all attachments as: .zip

Change History (20)

comment:1 by diver, 3 years ago

Blocking: 13899 added

comment:2 by mmlr, 3 years ago

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

by Pete, 3 years ago

Attachment: dummy.zip added

short zip file that (sometimes) shows directory attribute problem

comment:3 by Pete, 3 years ago

patch: 01

comment:4 by Pete, 3 years 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, 3 years 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, 3 years ago

patch: 10

comment:7 by AGMS, 3 years 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, 3 years 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, 3 years 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, 3 years 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, 3 years 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, 3 years 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, 2 years 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, 2 years ago

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

by vidrep, 2 years ago

Attachment: unzip_terminal.log added

comment:16 by AGMS, 2 years ago

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

comment:17 by GregCrain, 2 years 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 2 years ago by GregCrain (previous) (diff)

comment:18 by waddlesplash, 2 years 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.