[jira] [Updated] (COMPRESS-613) Write ZIP extra time fields automatically
[
https://issues.apache.org/jira/browse/COMPRESS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated COMPRESS-613:
-
External issue URL: https://github.com/apache/commons-compress/pull/345
> 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: 3h
> 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)
[jira] [Updated] (COMPRESS-613) Write ZIP extra time fields automatically
[
https://issues.apache.org/jira/browse/COMPRESS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andre Brait updated COMPRESS-613:
-
Description:
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}
was:
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 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)}}, repre
[jira] [Updated] (COMPRESS-613) Write ZIP extra time fields automatically
[
https://issues.apache.org/jira/browse/COMPRESS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andre Brait updated COMPRESS-613:
-
Description:
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 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}
was:
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 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.
> Write ZIP extra time fields automatically
> -
>
>
