Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#11023 closed bug (fixed)

zip loses all the file's attributes, when attributes > 64 KiB

Reported by: bbjimmy Owned by: nobody
Priority: high Milestone: R1/beta1
Component: Applications/Command Line Tools Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by luroh)

hrev 46791

zip loses all of the file attributes when the total number of bytes in attributes exceeds 64 KiB.

comments in beos.c: starting at line 430:

/* ----------------------------------------------------------------- */ /* Read all the attributes; the buffer could grow > 64K if there are */ /* many and/or they are large. */

It seems that the buffer cannot grow as intended, and if it should grow, all the attribute data is lost.

Change History (9)

comment:1 by waddlesplash, 5 years ago

Milestone: R1R1/alpha5
Priority: normalhigh

comment:2 by luroh, 5 years ago

Description: modified (diff)
Summary: zip looses all the file's attributeszip loses all the file's attributes

comment:3 by mmadia, 5 years ago

Summary: zip loses all the file's attributeszip loses all the file's attributes, when attributes > 64 KiB

comment:4 by pulkomandy, 5 years ago

The attributes aren't completely dropped, when trying to decompress I get this error (both with unzip 5.5.0 and 6.1 betas):

 extracting: plop                    
ERROR:  invalid compressed data to inflate
Error uncompressing file attributes.

It seems the function you pointed is correct (I dumped the output of it and it seems to be complete). After that the attributes are compressed using memcompress, and I thnk that's where things go wrong. In my test, a 140K attribute which contains the data of a zp file (so is already compressed) got reduced to less than 6K by memcompress. It seems that the memcompress function isn't working well.

comment:5 by pulkomandy, 5 years ago

Milestone: R1/alpha5R1/beta1

comment:6 by korli, 5 years ago

Resolution: fixed
Status: newclosed

I applied a "fix" for the problem in hrev48926. It doesn't actually fix adding attributes > 64kb because this can't possibly be done with the extra field maximal length of 65536. zip now warns about the problem and leaves attributes for the file out. I'm willing to close this ticket as fixed, as I think it's out of its scope to implement some support for bigger attributes.

comment:7 by bbjimmy, 5 years ago

Does this mean that haiku now has a 64kib limit on the attributes that a file can have? if not, then closing this ticket is just ignoring an issue.

comment:8 by pulkomandy, 5 years ago

It is a limitation of the zip format. We can't change the format (it would break compatibility with other tools and platforms), so all we can do is warn about the problem.

comment:9 by korli, 5 years ago

For reference:

Offset	Bytes	Description[25]
28	2	Extra field length (m)

The allowed length of 2 bytes limits the attributes to be stored per file.

This is on par with what MacOS implemented. Going beyond this limit is an enhancement, not an issue.

Note: See TracTickets for help on using tickets.