From: Peter Krefting <peter@softwolves.pp.se>
To: "René Scharfe" <l.s.r@web.de>
Cc: Johannes Sixt <j6t@kdbg.org>,
git@vger.kernel.org, Keith Goldfarb <keith@blackthorn-media.com>
Subject: Re: [PATCH v3 4/5] archive-zip: support archives bigger than 4GB
Date: Wed, 26 Apr 2017 22:02:33 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.11.1704262154420.29054@perkele.intern.softwolves.pp.se> (raw)
In-Reply-To: <fdc17512-94dc-4f7f-4fd3-f933e1b18e8f@web.de>
René Scharfe:
> I struggled with that sentence as well. There is no explicit
> "format" field AFAICS.
Exactly. I interpret that as it is in zip64 format if there are any
zip64 structures in the archive (especially if there is a zip64
end of central directory locator).
> Or in other words: A legacy ZIP archive and a ZIP64 archive can be
> bit-wise the same if all values for all entries fit into the legacy
> fields, but the difference in terms of the spec is what the archiver
> was allowed to do when it created them.
As long as all sizes are below (unsigned) -1, then they would be
identical. If one, and only one, of the sizes are equal to (unsigned)
-1 (and none overflow), then it is up to intepretation whether or not
a ZIP64-aware archiver is allowed to output an archive that is not in
ZIP64 format. If any single size or value overflows the 32 (16) bit
values, then ZIP64 format is needed.
> # 4-byte sizes, not ZIP64
> arch --format=zip ...
>
> # ZIP64, can use 8-byte sizes as needed
> arch --format=zip64 ...
>
> Makes sense?
Well, I would say that it would be a lot easier to always emit zip64
archives. An old-style unzipper should be able to read them anyway if
there are no overflowing fields, right? And, besides, who in 2017 has
an unzip tool that is unable to read zip64? Info-Zip UnZip has
supported Zip64 since 2009.
--
\\// Peter - http://www.softwolves.pp.se/
next prev parent reply other threads:[~2017-04-26 21:02 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-21 21:08 Git archive doesn't fully support zip64 Keith Goldfarb
2017-04-22 19:22 ` [PATCH] archive-zip: Add zip64 headers when file size is too large for 32 bits Peter Krefting
2017-04-22 21:52 ` Johannes Sixt
2017-04-22 22:41 ` [PATCH v2] " Peter Krefting
2017-04-23 7:50 ` Johannes Sixt
2017-04-23 14:51 ` Peter Krefting
2017-04-23 19:49 ` Johannes Sixt
2017-04-24 8:04 ` Peter Krefting
2017-04-24 12:04 ` René Scharfe
2017-04-24 17:22 ` [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB René Scharfe
2017-04-24 17:29 ` [PATCH v3 1/5] archive-zip: add tests for big ZIP archives René Scharfe
2017-04-24 17:30 ` [PATCH v3 2/5] archive-zip: use strbuf for ZIP directory René Scharfe
2017-04-25 4:51 ` Junio C Hamano
2017-04-25 5:28 ` René Scharfe
2017-04-24 17:31 ` [PATCH v3 3/5] archive-zip: write ZIP dir entry directly to strbuf René Scharfe
2017-04-24 17:32 ` [PATCH v3 4/5] archive-zip: support archives bigger than 4GB René Scharfe
2017-04-24 18:24 ` Peter Krefting
2017-04-24 20:06 ` René Scharfe
2017-04-24 20:39 ` René Scharfe
2017-04-24 21:02 ` Johannes Sixt
2017-04-24 21:41 ` René Scharfe
2017-04-25 7:55 ` Peter Krefting
2017-04-25 16:24 ` René Scharfe
2017-04-26 21:02 ` Peter Krefting [this message]
2017-04-26 23:38 ` René Scharfe
2017-04-27 4:57 ` Peter Krefting
2017-04-27 19:54 ` René Scharfe
2017-04-28 8:40 ` Peter Krefting
2017-04-24 17:33 ` [PATCH v3 5/5] archive-zip: support files " René Scharfe
2017-04-24 21:11 ` Keith Goldfarb
2017-04-25 4:46 ` Junio C Hamano
2017-04-25 5:27 ` René Scharfe
2017-04-29 21:00 ` [PATCH v3 0/5] archive-zip: support files and archives " Torsten Bögershausen
2017-04-29 22:28 ` René Scharfe
2017-04-30 5:31 ` Torsten Bögershausen
2017-04-30 7:53 ` René Scharfe
2017-04-30 13:06 ` Torsten Bögershausen
2017-04-30 16:32 ` Johannes Sixt
2017-04-30 16:40 ` René Scharfe
2017-04-30 23:49 ` Junio C Hamano
2017-05-01 8:30 ` René Scharfe
2017-04-23 0:16 ` [PATCH] archive-zip: Add zip64 headers when file size is too large for 32 bits René Scharfe
2017-04-23 6:42 ` Peter Krefting
2017-04-23 7:27 ` Johannes Sixt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.11.1704262154420.29054@perkele.intern.softwolves.pp.se \
--to=peter@softwolves.pp.se \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=keith@blackthorn-media.com \
--cc=l.s.r@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).