To revive a very old thread...
Catalina apparently does things differently and no longer is happy with these
ZipMBS files unless you do some more tweaks.
The solution is to properly set the "created by" version number field to &h0314:
dim zipVersionMadeBy as uint16 = &h0314 // 03 = unix. 14 hex
Thanks, Christian,
I believe Zip files have this version # in two places: in each [local file
header], as well as in the [central directory header] (in fact, the CDH has
'version made by' and 'version needed to extract' fields)
Oddly, in my testing, all that I needed to do was change a single
Am 04.06.2014 um 19:07 schrieb Tim Jones :
> Apple’s ZIP implementation assigns the same 000A version ID to both 32 and 64
> bit archives.
>
> It’s sounds like you should modify your mini zip library to use Apple’s
> version ID since the rest of the world really doesn’t care :).
>
I simply m
Apple’s ZIP implementation assigns the same 000A version ID to both 32 and 64
bit archives.
It’s sounds like you should modify your mini zip library to use Apple’s version
ID since the rest of the world really doesn’t care :).
Tim
On Jun 4, 2014, at 9:57 AM, Christian Schmitz
wrote:
>
> Am
Am 03.06.2014 um 22:43 schrieb Michael Diehr :
> If I take the zip64 file created by MBS, and change that one byte (from a
> 002D to 000A or 0014), then the Finder properly handles the file.
>
> I'm not sure what to do about this - it looks like it's a bug in the Finder,
> since the "version 4
Am 04.06.2014 um 17:14 schrieb Michael Diehr :
> I did try that but it didn't seem to change the version # output - does it
> work?
Not sure. It's part of the parameters in minizip library.
Seems to be 0 always for this parameter.
Ah, it writes 45 into header of file if 64bit is used and 20
I did try that but it didn't seem to change the version # output - does it
work?
If so, what do we pass for "versionMadeBy"? The Zip specification lists that as
a 2-byte value, not a Uint32...
Also, I was not sure what to pass for default values for strategy, password,
crcForCtyping, and als
Am 03.06.2014 um 23:54 schrieb Michael Diehr :
> Christian - perhaps you could offer us some control over the version # that's
> output in the zip files?
Well, the CreateFile function has several variants and one is with
versionMadeBy as integer. Maybe that helps?
CreateFile(Filename as stri
This little routine *seems* to fix zip64 format files so they work under OS X -
I wouldn't rely on this, but it's an interesting hack:
if bUseZip64 then
' fix a Zip64 file by manually altering the 5th byte from a &h2D to a
&h14
' this tricks OS X so it will understand Zip6
I did some quick tests, comparing three files:
1. Zip file generated by MBS
2. Zip64 file generated by MBS
3. Zip file generated by OS X Finder (which I believe uses 'ditto')
Using the Zip format specification
http://www.pkware.com/documents/casestudies/APPNOTE.TXT
The files have differences, p
I just tried it, and it seems the same problem reported a long time ago by
David Glass. I'm seeing the same thing in 10.8.5:
"Developing with RS 2011r3, on 10.6.8, with MBS 11.2.
When I create a zip file (ZipMBS.CreateFile) I'm experiencing the
following results from the file created:
Applica
I'll give the 14.2pr version a try and report back.
On Jun 2, 2014, at 3:02 PM, Christian Schmitz
wrote:
>
> Am 02.06.2014 um 23:31 schrieb Michael Diehr :
>
>> Hi Christian,
>>
>> Does the Zip64 support in the ZipMBS classes still not work? The
>> documentation says
>
> I thought I fixe
Am 02.06.2014 um 23:31 schrieb Michael Diehr :
> Hi Christian,
>
> Does the Zip64 support in the ZipMBS classes still not work? The
> documentation says
I thought I fixed those little problems.
Did someone try recently with 14.2 plugins?
Sincerely
Christian
--
Read our blog about news on
Hi Christian,
Does the Zip64 support in the ZipMBS classes still not work? The documentation
says
"In plugin version 11.1 we added zip64 flags for CreateFile method so you can
create bigger zip archives. Still it seems not to work for our test to have zip
archives bigger than 2 GB."
__
14 matches
Mail list logo