[
https://issues.apache.org/jira/browse/COMPRESS-613?focusedWorklogId=836181&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-836181
]
ASF GitHub Bot logged work on COMPRESS-613:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 30/Dec/22 00:03
Start Date: 30/Dec/22 00:03
Worklog Time Spent: 10m
Work Description: andrebrait commented on code in PR #345:
URL: https://github.com/apache/commons-compress/pull/345#discussion_r1059195453
##########
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##########
@@ -68,7 +68,14 @@
* @NotThreadSafe
*/
public class X000A_NTFS implements ZipExtraField {
- private static final ZipShort HEADER_ID = new ZipShort(0x000a);
+
+ /**
+ * The header ID for this extra field.
+ *
+ * @since 1.23
+ */
+ public static final ZipShort HEADER_ID = new ZipShort(0x000a);
Review Comment:
Will do if it works properly.
The reason for making it public was that I was testing it before with my
project that uses commons-compress and I had it public to be able to use it
there. I was getting the extra field directly.
But tbh, it makes perfect sense to let it be public if we also have a public
method kn ZipArchiveEntry to fetch an ExtraField based on a ZipLong containing
its identifier. I know having a small API is important, but should anyone need
to fetch that extra field (which is allowed using ZipArchiveEntry) it's quite
frustrating, as the user, that I need to maintain a bunch of my own constants,
copied from this class, instead of having this class expose this itself.
Issue Time Tracking
-------------------
Worklog Id: (was: 836181)
Time Spent: 1h 20m (was: 1h 10m)
> Write ZIP extra time fields automatically
> -----------------------------------------
>
> Key: COMPRESS-613
> URL: https://issues.apache.org/jira/browse/COMPRESS-613
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
> Affects Versions: 1.21
> Reporter: Andre Brait
> Priority: Major
> Labels: zip
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When writing to a Zip file through ZipArchiveOutputStream, setting creation
> and access times in a ZipArchiveEntry does not cause these to be reflected as
> X5455 or X000A extra fields in the resulting zip file. This also happens for
> modification times that do not fit into an MS-DOS time.
> As a consequence, the date range is reduced, as well as the granularity (form
> 100ns intervals to seconds).
> ZipEntry and standard java.util.zip facilities do that automatically, but
> that's missing here.
> My proposal is to use the same logic the java.util.zip do and add those extra
> fields automatically, if situation requires them.
> See my existing logic for this here:
> [https://github.com/andrebrait/DATROMTool/blob/86a4f4978bab250ca54d047c58b4f91e7dbbcc7f/core/src/main/java/io/github/datromtool/io/FileCopier.java#L1425]
> It's (almost) the same logic from java.util.zip, but adapted to be used with
> ZipArchiveEntry.
> If you're ok with it, I can send a PR.
> Actual logic will be more like
> {{{}java.util.zip.ZipOutputStream#writeLOC(XEntry){}}}, represented below:
> {code:java}
> int elenEXTT = 0; // info-zip extended timestamp
> int flagEXTT = 0;
> long umtime = -1;
> long uatime = -1;
> long uctime = -1;
> if (e.mtime != null) {
> elenEXTT += 4;
> flagEXTT |= EXTT_FLAG_LMT;
> umtime = fileTimeToUnixTime(e.mtime);
> }
> if (e.atime != null) {
> elenEXTT += 4;
> flagEXTT |= EXTT_FLAG_LAT;
> uatime = fileTimeToUnixTime(e.atime);
> }
> if (e.ctime != null) {
> elenEXTT += 4;
> flagEXTT |= EXTT_FLAT_CT;
> uctime = fileTimeToUnixTime(e.ctime);
> }
> if (flagEXTT != 0) {
> // to use ntfs time if any m/a/ctime is beyond unixtime upper
> bound
> if (umtime > UPPER_UNIXTIME_BOUND ||
> uatime > UPPER_UNIXTIME_BOUND ||
> uctime > UPPER_UNIXTIME_BOUND) {
> elen += 36; // NTFS time, total 36 bytes
> } else {
> elen += (elenEXTT + 5); // headid(2) + size(2) + flag(1) +
> data
> }
> }
> writeShort(elen);
> writeBytes(nameBytes, 0, nameBytes.length);
> if (hasZip64) {
> writeShort(ZIP64_EXTID);
> writeShort(16);
> writeLong(e.size);
> writeLong(e.csize);
> }
> if (flagEXTT != 0) {
> if (umtime > UPPER_UNIXTIME_BOUND ||
> uatime > UPPER_UNIXTIME_BOUND ||
> uctime > UPPER_UNIXTIME_BOUND) {
> writeShort(EXTID_NTFS); // id
> writeShort(32); // data size
> writeInt(0); // reserved
> writeShort(0x0001); // NTFS attr tag
> writeShort(24);
> writeLong(e.mtime == null ? WINDOWS_TIME_NOT_AVAILABLE
> : fileTimeToWinTime(e.mtime));
> writeLong(e.atime == null ? WINDOWS_TIME_NOT_AVAILABLE
> : fileTimeToWinTime(e.atime));
> writeLong(e.ctime == null ? WINDOWS_TIME_NOT_AVAILABLE
> : fileTimeToWinTime(e.ctime));
> } else {
> writeShort(EXTID_EXTT);
> writeShort(elenEXTT + 1); // flag + data
> writeByte(flagEXTT);
> if (e.mtime != null)
> writeInt(umtime);
> if (e.atime != null)
> writeInt(uatime);
> if (e.ctime != null)
> writeInt(uctime);
> }
> }
> writeExtra(e.extra);
> locoff = written;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
