[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=744306&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-744306 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 18/Mar/22 18:27 Start Date: 18/Mar/22 18:27 Worklog Time Spent: 10m Work Description: garydgregory merged pull request #254: URL: https://github.com/apache/commons-compress/pull/254 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 744306) Time Spent: 3.5h (was: 3h 20m) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 3.5h > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=744292&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-744292 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 18/Mar/22 18:10 Start Date: 18/Mar/22 18:10 Worklog Time Spent: 10m Work Description: andrebrait commented on pull request #254: URL: https://github.com/apache/commons-compress/pull/254#issuecomment-1072666968 Hi @garydgregory. Let me know if there's anything else you'd like me to change here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 744292) Time Spent: 3h 20m (was: 3h 10m) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 3h 20m > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=744291&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-744291 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 18/Mar/22 18:10 Start Date: 18/Mar/22 18:10 Worklog Time Spent: 10m Work Description: andrebrait commented on a change in pull request #254: URL: https://github.com/apache/commons-compress/pull/254#discussion_r830242247 ## File path: src/main/java/org/apache/commons/compress/archivers/tar/TarConstants.java ## @@ -347,6 +361,13 @@ */ String MAGIC_XSTAR = "tar\0"; +/** + * Offset inside the header for the xtar multivolume data + * Review comment: I see there's no support for multivolume TAR archives yet. I decided to only add the `@see` bits in the offset constants I added and to add a note on the multivolume check for xstar for clarity. The whole section was taken from star anyway, so I trust it is correct. See 07d34a2. Regardless, the `M` link flag is a GNU/xstar-specific extension that's only used in multivolume archives, which compress currently doesn't support, so that code is there more for documentation/future-proofing than anything else. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 744291) Time Spent: 3h 10m (was: 3h) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 3h 10m > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[
https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=744083&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-744083
]
ASF GitHub Bot logged work on COMPRESS-612:
---
Author: ASF GitHub Bot
Created on: 18/Mar/22 15:03
Start Date: 18/Mar/22 15:03
Worklog Time Spent: 10m
Work Description: andrebrait commented on a change in pull request #254:
URL: https://github.com/apache/commons-compress/pull/254#discussion_r829051239
##
File path:
src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveEntryTest.java
##
@@ -306,6 +308,164 @@ public void
getOrderedSparseHeadersRejectsStructsPointingBeyondOutputEntry() thr
te.getOrderedSparseHeaders();
}
+@Test
+public void shouldParseTimePaxHeadersAndNotCountAsExtraPaxHeaders() {
+TarArchiveEntry entry = createEntryForTimeTests();
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("size", entry.getExtraPaxHeader("size"));
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("size", entry.getSize(), 1);
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03.599853900Z")),
entry.getLastModifiedTime());
+assertEquals("atime",
FileTime.from(Instant.parse("2022-03-14T01:31:00.706927200Z")),
entry.getLastAccessTime());
+assertEquals("ctime",
FileTime.from(Instant.parse("2022-03-14T01:28:59.700505300Z")),
entry.getStatusChangeTime());
+assertEquals("birthtime",
FileTime.from(Instant.parse("2022-03-14T01:29:00.723509000Z")),
entry.getCreationTime());
+}
+
+@Test
+public void shouldNotWriteTimePaxHeadersByDefault() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
Review comment:
I'd think that would be an antipattern in a way, because I'd have to get
the data from the BAOS before both it and the TarArchiveOutputStream are closed
if both are on the same try-with-resources, which is generally not a good idea
with some OutputStream implementations.
I'd rather have them nested to ensure the TarArchiveOutputStream is closed
before getting the data from the BAOS as that's the safest thing to do in most
scenarios.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 744083)
Time Spent: 3h (was: 2h 50m)
> Support atime/ctime and higher time precision for TAR
> -
>
> Key: COMPRESS-612
> URL: https://issues.apache.org/jira/browse/COMPRESS-612
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Andre Brait
>Priority: Major
> Labels: tar
> Time Spent: 3h
> Remaining Estimate: 0h
>
> This is a proposal for some code I have already worked on.
> h3. Context
> I'm coding a tool that requires extracting/compressing files. I noticed the
> following shortcomings:
> - -File size is limited to 8GB. This limitation was lifted as of
> POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger
> files are fully supported by some TAR archiving tools such as GNU TAR.
> Reference:
> [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]-
> -- I think I was actually wrong here in that current implementation should
> support files >8GB if using BIGNUMBER_POSIX.
> - Only modification date is available as a time type.
> - Maximum granularity is seconds, even though the PAX header contains 100ns
> intervals
> - Other time-related PAX headers are considered extra headers (ctime and
> atime)
> My proposal is as follows:
> - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime
> - Keep backwards compatibility through getter/setter methods and add new
> ones for FileTime
> - Parse times in with a maximal granularity of 100ns intervals from PAX
> headers
> - Read/write ctime and atime and add corresponding fields
> - Write times to PAX headers using a maximum granularity of 100ns intervals
> when in BIGNUMBER_POSIX mode.
> - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowin
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[
https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=744012&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-744012
]
ASF GitHub Bot logged work on COMPRESS-612:
---
Author: ASF GitHub Bot
Created on: 18/Mar/22 14:57
Start Date: 18/Mar/22 14:57
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #254:
URL: https://github.com/apache/commons-compress/pull/254#discussion_r829048618
##
File path:
src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveEntryTest.java
##
@@ -306,6 +308,164 @@ public void
getOrderedSparseHeadersRejectsStructsPointingBeyondOutputEntry() thr
te.getOrderedSparseHeaders();
}
+@Test
+public void shouldParseTimePaxHeadersAndNotCountAsExtraPaxHeaders() {
+TarArchiveEntry entry = createEntryForTimeTests();
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("size", entry.getExtraPaxHeader("size"));
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("size", entry.getSize(), 1);
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03.599853900Z")),
entry.getLastModifiedTime());
+assertEquals("atime",
FileTime.from(Instant.parse("2022-03-14T01:31:00.706927200Z")),
entry.getLastAccessTime());
+assertEquals("ctime",
FileTime.from(Instant.parse("2022-03-14T01:28:59.700505300Z")),
entry.getStatusChangeTime());
+assertEquals("birthtime",
FileTime.from(Instant.parse("2022-03-14T01:29:00.723509000Z")),
entry.getCreationTime());
+}
+
+@Test
+public void shouldNotWriteTimePaxHeadersByDefault() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
Review comment:
Leave it as is then. I don't think you'd need need nested try-w-res
since you can have >1 statement in a try. But it's a detail we do not need to
deal with as a requirement for this PR to make it. I'll leave it up to you.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 744012)
Time Spent: 2h 50m (was: 2h 40m)
> Support atime/ctime and higher time precision for TAR
> -
>
> Key: COMPRESS-612
> URL: https://issues.apache.org/jira/browse/COMPRESS-612
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Andre Brait
>Priority: Major
> Labels: tar
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This is a proposal for some code I have already worked on.
> h3. Context
> I'm coding a tool that requires extracting/compressing files. I noticed the
> following shortcomings:
> - -File size is limited to 8GB. This limitation was lifted as of
> POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger
> files are fully supported by some TAR archiving tools such as GNU TAR.
> Reference:
> [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]-
> -- I think I was actually wrong here in that current implementation should
> support files >8GB if using BIGNUMBER_POSIX.
> - Only modification date is available as a time type.
> - Maximum granularity is seconds, even though the PAX header contains 100ns
> intervals
> - Other time-related PAX headers are considered extra headers (ctime and
> atime)
> My proposal is as follows:
> - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime
> - Keep backwards compatibility through getter/setter methods and add new
> ones for FileTime
> - Parse times in with a maximal granularity of 100ns intervals from PAX
> headers
> - Read/write ctime and atime and add corresponding fields
> - Write times to PAX headers using a maximum granularity of 100ns intervals
> when in BIGNUMBER_POSIX mode.
> - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for
> the bigger size, mtime, ctime and atime to be written-
> - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001-
> I already have some code for that in
> https://github.com/andrebrait/commons-compress/tree
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[
https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=743106&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-743106
]
ASF GitHub Bot logged work on COMPRESS-612:
---
Author: ASF GitHub Bot
Created on: 17/Mar/22 12:13
Start Date: 17/Mar/22 12:13
Worklog Time Spent: 10m
Work Description: andrebrait commented on a change in pull request #254:
URL: https://github.com/apache/commons-compress/pull/254#discussion_r829051239
##
File path:
src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveEntryTest.java
##
@@ -306,6 +308,164 @@ public void
getOrderedSparseHeadersRejectsStructsPointingBeyondOutputEntry() thr
te.getOrderedSparseHeaders();
}
+@Test
+public void shouldParseTimePaxHeadersAndNotCountAsExtraPaxHeaders() {
+TarArchiveEntry entry = createEntryForTimeTests();
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("size", entry.getExtraPaxHeader("size"));
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("size", entry.getSize(), 1);
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03.599853900Z")),
entry.getLastModifiedTime());
+assertEquals("atime",
FileTime.from(Instant.parse("2022-03-14T01:31:00.706927200Z")),
entry.getLastAccessTime());
+assertEquals("ctime",
FileTime.from(Instant.parse("2022-03-14T01:28:59.700505300Z")),
entry.getStatusChangeTime());
+assertEquals("birthtime",
FileTime.from(Instant.parse("2022-03-14T01:29:00.723509000Z")),
entry.getCreationTime());
+}
+
+@Test
+public void shouldNotWriteTimePaxHeadersByDefault() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
Review comment:
I'd think that would be an antipattern in a way, because I'd have to get
the data from the BAOS before both it and the TarArchiveOutputStream are closed
if both are on the same try-with-resources, which is generally not a good idea
with some OutputStream implementations.
I'd rather have them nested to ensure the TarArchiveOutputStream is closed
before getting the data from the BAOS as that's the safest thing to do in most
scenarios.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 743106)
Time Spent: 2h 40m (was: 2.5h)
> Support atime/ctime and higher time precision for TAR
> -
>
> Key: COMPRESS-612
> URL: https://issues.apache.org/jira/browse/COMPRESS-612
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Andre Brait
>Priority: Major
> Labels: tar
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> This is a proposal for some code I have already worked on.
> h3. Context
> I'm coding a tool that requires extracting/compressing files. I noticed the
> following shortcomings:
> - -File size is limited to 8GB. This limitation was lifted as of
> POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger
> files are fully supported by some TAR archiving tools such as GNU TAR.
> Reference:
> [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]-
> -- I think I was actually wrong here in that current implementation should
> support files >8GB if using BIGNUMBER_POSIX.
> - Only modification date is available as a time type.
> - Maximum granularity is seconds, even though the PAX header contains 100ns
> intervals
> - Other time-related PAX headers are considered extra headers (ctime and
> atime)
> My proposal is as follows:
> - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime
> - Keep backwards compatibility through getter/setter methods and add new
> ones for FileTime
> - Parse times in with a maximal granularity of 100ns intervals from PAX
> headers
> - Read/write ctime and atime and add corresponding fields
> - Write times to PAX headers using a maximum granularity of 100ns intervals
> when in BIGNUMBER_POSIX mode.
> - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, a
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[
https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=743104&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-743104
]
ASF GitHub Bot logged work on COMPRESS-612:
---
Author: ASF GitHub Bot
Created on: 17/Mar/22 12:09
Start Date: 17/Mar/22 12:09
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #254:
URL: https://github.com/apache/commons-compress/pull/254#discussion_r829048618
##
File path:
src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveEntryTest.java
##
@@ -306,6 +308,164 @@ public void
getOrderedSparseHeadersRejectsStructsPointingBeyondOutputEntry() thr
te.getOrderedSparseHeaders();
}
+@Test
+public void shouldParseTimePaxHeadersAndNotCountAsExtraPaxHeaders() {
+TarArchiveEntry entry = createEntryForTimeTests();
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("size", entry.getExtraPaxHeader("size"));
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("size", entry.getSize(), 1);
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03.599853900Z")),
entry.getLastModifiedTime());
+assertEquals("atime",
FileTime.from(Instant.parse("2022-03-14T01:31:00.706927200Z")),
entry.getLastAccessTime());
+assertEquals("ctime",
FileTime.from(Instant.parse("2022-03-14T01:28:59.700505300Z")),
entry.getStatusChangeTime());
+assertEquals("birthtime",
FileTime.from(Instant.parse("2022-03-14T01:29:00.723509000Z")),
entry.getCreationTime());
+}
+
+@Test
+public void shouldNotWriteTimePaxHeadersByDefault() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
Review comment:
Leave it as is then. I don't think you'd need need nested try-w-res
since you can have >1 statement in a try. But it's a detail we do not need to
deal with as a requirement for this PR to make it. I'll leave it up to you.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 743104)
Time Spent: 2.5h (was: 2h 20m)
> Support atime/ctime and higher time precision for TAR
> -
>
> Key: COMPRESS-612
> URL: https://issues.apache.org/jira/browse/COMPRESS-612
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Andre Brait
>Priority: Major
> Labels: tar
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is a proposal for some code I have already worked on.
> h3. Context
> I'm coding a tool that requires extracting/compressing files. I noticed the
> following shortcomings:
> - -File size is limited to 8GB. This limitation was lifted as of
> POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger
> files are fully supported by some TAR archiving tools such as GNU TAR.
> Reference:
> [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]-
> -- I think I was actually wrong here in that current implementation should
> support files >8GB if using BIGNUMBER_POSIX.
> - Only modification date is available as a time type.
> - Maximum granularity is seconds, even though the PAX header contains 100ns
> intervals
> - Other time-related PAX headers are considered extra headers (ctime and
> atime)
> My proposal is as follows:
> - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime
> - Keep backwards compatibility through getter/setter methods and add new
> ones for FileTime
> - Parse times in with a maximal granularity of 100ns intervals from PAX
> headers
> - Read/write ctime and atime and add corresponding fields
> - Write times to PAX headers using a maximum granularity of 100ns intervals
> when in BIGNUMBER_POSIX mode.
> - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for
> the bigger size, mtime, ctime and atime to be written-
> - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001-
> I already have some code for that in
> https://github.com/andrebrait/commons-compress/tree/COM
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=743087&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-743087 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 17/Mar/22 11:17 Start Date: 17/Mar/22 11:17 Worklog Time Spent: 10m Work Description: andrebrait commented on a change in pull request #254: URL: https://github.com/apache/commons-compress/pull/254#discussion_r829009791 ## File path: src/main/java/org/apache/commons/compress/archivers/tar/TarConstants.java ## @@ -347,6 +361,13 @@ */ String MAGIC_XSTAR = "tar\0"; +/** + * Offset inside the header for the xtar multivolume data + * Review comment: Ok. Will do. Just an FYI, I'm gonna add a couple test cases for multi volume ustar, posix/expax and xstar/xustar files just to be 100% sure it's handling that correctly. I should have the commit by the end of the day. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 743087) Time Spent: 2h 20m (was: 2h 10m) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 2h 20m > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=743085&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-743085 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 17/Mar/22 11:09 Start Date: 17/Mar/22 11:09 Worklog Time Spent: 10m Work Description: garydgregory commented on a change in pull request #254: URL: https://github.com/apache/commons-compress/pull/254#discussion_r829004057 ## File path: src/main/java/org/apache/commons/compress/archivers/tar/TarConstants.java ## @@ -347,6 +361,13 @@ */ String MAGIC_XSTAR = "tar\0"; +/** + * Offset inside the header for the xtar multivolume data + * Review comment: If you've already documented it well in one place you can just use "@see" to that place. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 743085) Time Spent: 2h 10m (was: 2h) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 2h 10m > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=743084&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-743084 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 17/Mar/22 11:09 Start Date: 17/Mar/22 11:09 Worklog Time Spent: 10m Work Description: garydgregory commented on a change in pull request #254: URL: https://github.com/apache/commons-compress/pull/254#discussion_r829004057 ## File path: src/main/java/org/apache/commons/compress/archivers/tar/TarConstants.java ## @@ -347,6 +361,13 @@ */ String MAGIC_XSTAR = "tar\0"; +/** + * Offset inside the header for the xtar multivolume data + * Review comment: If you've already documented well on one place you can just use "@see" to that place. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 743084) Time Spent: 2h (was: 1h 50m) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 2h > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=742929&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-742929 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 17/Mar/22 02:35 Start Date: 17/Mar/22 02:35 Worklog Time Spent: 10m Work Description: andrebrait commented on a change in pull request #254: URL: https://github.com/apache/commons-compress/pull/254#discussion_r828704148 ## File path: src/main/java/org/apache/commons/compress/archivers/tar/TarConstants.java ## @@ -347,6 +361,13 @@ */ String MAGIC_XSTAR = "tar\0"; +/** + * Offset inside the header for the xtar multivolume data + * Review comment: I derived it from [star's source code](https://sourceforge.net/projects/s-tar/files/star-1.6.tar.bz2). Specifically, `star.h`, line 400, which you can also view [here](https://fossies.org/linux/misc/star-1.6.tar.bz2/star-1.6/star/star.h). I also added the struct and the offsets at the javadoc for `TarArchiveEntry`. Would you like me to find a way to incorporate a link or pointer to the source code? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 742929) Time Spent: 1h 50m (was: 1h 40m) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 1h 50m > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[
https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=742925&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-742925
]
ASF GitHub Bot logged work on COMPRESS-612:
---
Author: ASF GitHub Bot
Created on: 17/Mar/22 02:27
Start Date: 17/Mar/22 02:27
Worklog Time Spent: 10m
Work Description: andrebrait commented on a change in pull request #254:
URL: https://github.com/apache/commons-compress/pull/254#discussion_r828693120
##
File path:
src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveEntryTest.java
##
@@ -306,6 +308,164 @@ public void
getOrderedSparseHeadersRejectsStructsPointingBeyondOutputEntry() thr
te.getOrderedSparseHeaders();
}
+@Test
+public void shouldParseTimePaxHeadersAndNotCountAsExtraPaxHeaders() {
+TarArchiveEntry entry = createEntryForTimeTests();
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("size", entry.getExtraPaxHeader("size"));
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("size", entry.getSize(), 1);
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03.599853900Z")),
entry.getLastModifiedTime());
+assertEquals("atime",
FileTime.from(Instant.parse("2022-03-14T01:31:00.706927200Z")),
entry.getLastAccessTime());
+assertEquals("ctime",
FileTime.from(Instant.parse("2022-03-14T01:28:59.700505300Z")),
entry.getStatusChangeTime());
+assertEquals("birthtime",
FileTime.from(Instant.parse("2022-03-14T01:29:00.723509000Z")),
entry.getCreationTime());
+}
+
+@Test
+public void shouldNotWriteTimePaxHeadersByDefault() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
+final TarArchiveOutputStream tos = new TarArchiveOutputStream(bos);
+tos.putArchiveEntry(entry);
+tos.write('W');
+tos.closeArchiveEntry();
+tos.close();
+
+final TarArchiveInputStream tis = new TarArchiveInputStream(new
ByteArrayInputStream(bos.toByteArray()));
+entry = tis.getNextTarEntry();
+assertNotNull("couldn't get entry", entry);
+
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03Z")),
entry.getLastModifiedTime());
+assertNull("atime", entry.getLastAccessTime());
+assertNull("ctime", entry.getStatusChangeTime());
+assertNull("birthtime", entry.getCreationTime());
+
+assertEquals('W', tis.read());
+assertTrue("should be at end of entry", tis.read() < 0);
+
+assertNull("should be at end of file", tis.getNextTarEntry());
+tis.close();
+}
+
+@Test
+public void shouldWriteTimesForStarMode() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
Review comment:
Done
##
File path:
src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveEntryTest.java
##
@@ -306,6 +308,164 @@ public void
getOrderedSparseHeadersRejectsStructsPointingBeyondOutputEntry() thr
te.getOrderedSparseHeaders();
}
+@Test
+public void shouldParseTimePaxHeadersAndNotCountAsExtraPaxHeaders() {
+TarArchiveEntry entry = createEntryForTimeTests();
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("size", entry.getExtraPaxHeader("size"));
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("size", entry.getSize(), 1);
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03.599853900Z")),
entry.getLastModifiedTime());
+assertEquals("atime",
FileTime.from(Instant.parse("2022-03-14T01:31:00.706927200Z")),
entry.getLastAccessTime());
+assertEquals("ctime",
FileTime.from(Instant.parse("2022-03-14T01:28:59.700505300Z")),
entry.getStatusChangeTime());
+asse
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[
https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=742924&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-742924
]
ASF GitHub Bot logged work on COMPRESS-612:
---
Author: ASF GitHub Bot
Created on: 17/Mar/22 02:26
Start Date: 17/Mar/22 02:26
Worklog Time Spent: 10m
Work Description: andrebrait commented on a change in pull request #254:
URL: https://github.com/apache/commons-compress/pull/254#discussion_r828692852
##
File path:
src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveEntryTest.java
##
@@ -306,6 +308,164 @@ public void
getOrderedSparseHeadersRejectsStructsPointingBeyondOutputEntry() thr
te.getOrderedSparseHeaders();
}
+@Test
+public void shouldParseTimePaxHeadersAndNotCountAsExtraPaxHeaders() {
+TarArchiveEntry entry = createEntryForTimeTests();
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("size", entry.getExtraPaxHeader("size"));
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("size", entry.getSize(), 1);
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03.599853900Z")),
entry.getLastModifiedTime());
+assertEquals("atime",
FileTime.from(Instant.parse("2022-03-14T01:31:00.706927200Z")),
entry.getLastAccessTime());
+assertEquals("ctime",
FileTime.from(Instant.parse("2022-03-14T01:28:59.700505300Z")),
entry.getStatusChangeTime());
+assertEquals("birthtime",
FileTime.from(Instant.parse("2022-03-14T01:29:00.723509000Z")),
entry.getCreationTime());
+}
+
+@Test
+public void shouldNotWriteTimePaxHeadersByDefault() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
Review comment:
Btw, I can maybe add try-with-resouces on this ByteArrayOutputStream,
but the TarArchiveOutputStream's close methd already closes the BAOS as well.
If I do add the BAOS to the try-with-resources, I'll have to create a byte
array to save its internal byte array after closing the TarArchiveOutputStream,
meaning a nested try-with-resources. Let me know what you prefer, as both are
ok examples because of how TarArchiveOutputStream works.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 742924)
Time Spent: 1.5h (was: 1h 20m)
> Support atime/ctime and higher time precision for TAR
> -
>
> Key: COMPRESS-612
> URL: https://issues.apache.org/jira/browse/COMPRESS-612
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Andre Brait
>Priority: Major
> Labels: tar
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> This is a proposal for some code I have already worked on.
> h3. Context
> I'm coding a tool that requires extracting/compressing files. I noticed the
> following shortcomings:
> - -File size is limited to 8GB. This limitation was lifted as of
> POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger
> files are fully supported by some TAR archiving tools such as GNU TAR.
> Reference:
> [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]-
> -- I think I was actually wrong here in that current implementation should
> support files >8GB if using BIGNUMBER_POSIX.
> - Only modification date is available as a time type.
> - Maximum granularity is seconds, even though the PAX header contains 100ns
> intervals
> - Other time-related PAX headers are considered extra headers (ctime and
> atime)
> My proposal is as follows:
> - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime
> - Keep backwards compatibility through getter/setter methods and add new
> ones for FileTime
> - Parse times in with a maximal granularity of 100ns intervals from PAX
> headers
> - Read/write ctime and atime and add corresponding fields
> - Write times to PAX headers using a maximum granularity of 100ns intervals
> when in BIGNUMBER_POSIX mode.
> - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[
https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=742923&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-742923
]
ASF GitHub Bot logged work on COMPRESS-612:
---
Author: ASF GitHub Bot
Created on: 17/Mar/22 02:23
Start Date: 17/Mar/22 02:23
Worklog Time Spent: 10m
Work Description: andrebrait commented on a change in pull request #254:
URL: https://github.com/apache/commons-compress/pull/254#discussion_r828688592
##
File path:
src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveEntryTest.java
##
@@ -306,6 +308,164 @@ public void
getOrderedSparseHeadersRejectsStructsPointingBeyondOutputEntry() thr
te.getOrderedSparseHeaders();
}
+@Test
+public void shouldParseTimePaxHeadersAndNotCountAsExtraPaxHeaders() {
+TarArchiveEntry entry = createEntryForTimeTests();
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("size", entry.getExtraPaxHeader("size"));
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("size", entry.getSize(), 1);
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03.599853900Z")),
entry.getLastModifiedTime());
+assertEquals("atime",
FileTime.from(Instant.parse("2022-03-14T01:31:00.706927200Z")),
entry.getLastAccessTime());
+assertEquals("ctime",
FileTime.from(Instant.parse("2022-03-14T01:28:59.700505300Z")),
entry.getStatusChangeTime());
+assertEquals("birthtime",
FileTime.from(Instant.parse("2022-03-14T01:29:00.723509000Z")),
entry.getCreationTime());
+}
+
+@Test
+public void shouldNotWriteTimePaxHeadersByDefault() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
Review comment:
Done
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 742923)
Time Spent: 1h 20m (was: 1h 10m)
> Support atime/ctime and higher time precision for TAR
> -
>
> Key: COMPRESS-612
> URL: https://issues.apache.org/jira/browse/COMPRESS-612
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Andre Brait
>Priority: Major
> Labels: tar
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> This is a proposal for some code I have already worked on.
> h3. Context
> I'm coding a tool that requires extracting/compressing files. I noticed the
> following shortcomings:
> - -File size is limited to 8GB. This limitation was lifted as of
> POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger
> files are fully supported by some TAR archiving tools such as GNU TAR.
> Reference:
> [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]-
> -- I think I was actually wrong here in that current implementation should
> support files >8GB if using BIGNUMBER_POSIX.
> - Only modification date is available as a time type.
> - Maximum granularity is seconds, even though the PAX header contains 100ns
> intervals
> - Other time-related PAX headers are considered extra headers (ctime and
> atime)
> My proposal is as follows:
> - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime
> - Keep backwards compatibility through getter/setter methods and add new
> ones for FileTime
> - Parse times in with a maximal granularity of 100ns intervals from PAX
> headers
> - Read/write ctime and atime and add corresponding fields
> - Write times to PAX headers using a maximum granularity of 100ns intervals
> when in BIGNUMBER_POSIX mode.
> - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for
> the bigger size, mtime, ctime and atime to be written-
> - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001-
> I already have some code for that in
> https://github.com/andrebrait/commons-compress/tree/COMPRESS-612
> Since compatibility with Android now requires API level 26 and that includes
> FileTime, I think we can do that here as well.
> This will bring tar in line with Zip in this regard.
--
This message was
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[
https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=742922&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-742922
]
ASF GitHub Bot logged work on COMPRESS-612:
---
Author: ASF GitHub Bot
Created on: 17/Mar/22 02:22
Start Date: 17/Mar/22 02:22
Worklog Time Spent: 10m
Work Description: andrebrait commented on a change in pull request #254:
URL: https://github.com/apache/commons-compress/pull/254#discussion_r828686673
##
File path:
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveOutputStream.java
##
@@ -624,11 +635,48 @@ private void addPaxHeaderForBigNumber(final Map paxHeaders,
}
}
+private void addFileTimePaxHeaderForBigNumber(final Map
paxHeaders,
+final String header, final FileTime value,
+final long maxValue) {
+if (value != null) {
+Instant instant = value.toInstant();
+long seconds = instant.getEpochSecond();
+int nanos = instant.getNano();
+if (nanos == 0) {
+addPaxHeaderForBigNumber(paxHeaders, header, seconds,
maxValue);
+} else {
+addInstantPaxHeader(paxHeaders, header, seconds, nanos);
+}
+}
+}
+
+private void addFileTimePaxHeader(final Map paxHeaders,
+final String header, final FileTime value) {
+if (value != null) {
+Instant instant = value.toInstant();
Review comment:
Done
##
File path:
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveOutputStream.java
##
@@ -624,11 +635,48 @@ private void addPaxHeaderForBigNumber(final Map paxHeaders,
}
}
+private void addFileTimePaxHeaderForBigNumber(final Map
paxHeaders,
+final String header, final FileTime value,
+final long maxValue) {
+if (value != null) {
+Instant instant = value.toInstant();
Review comment:
Done
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 742922)
Time Spent: 1h 10m (was: 1h)
> Support atime/ctime and higher time precision for TAR
> -
>
> Key: COMPRESS-612
> URL: https://issues.apache.org/jira/browse/COMPRESS-612
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Andre Brait
>Priority: Major
> Labels: tar
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is a proposal for some code I have already worked on.
> h3. Context
> I'm coding a tool that requires extracting/compressing files. I noticed the
> following shortcomings:
> - -File size is limited to 8GB. This limitation was lifted as of
> POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger
> files are fully supported by some TAR archiving tools such as GNU TAR.
> Reference:
> [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]-
> -- I think I was actually wrong here in that current implementation should
> support files >8GB if using BIGNUMBER_POSIX.
> - Only modification date is available as a time type.
> - Maximum granularity is seconds, even though the PAX header contains 100ns
> intervals
> - Other time-related PAX headers are considered extra headers (ctime and
> atime)
> My proposal is as follows:
> - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime
> - Keep backwards compatibility through getter/setter methods and add new
> ones for FileTime
> - Parse times in with a maximal granularity of 100ns intervals from PAX
> headers
> - Read/write ctime and atime and add corresponding fields
> - Write times to PAX headers using a maximum granularity of 100ns intervals
> when in BIGNUMBER_POSIX mode.
> - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for
> the bigger size, mtime, ctime and atime to be written-
> - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001-
> I already have some code for that in
> https://github.com/andrebrait/commons-compress/tree/COMPRESS-612
> Since compatibility with Android now requires API level 26 and that includes
> FileTime, I think we can do that here as well.
> This will bring tar in line with Zip in this regard.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=742921&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-742921 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 17/Mar/22 02:21 Start Date: 17/Mar/22 02:21 Worklog Time Spent: 10m Work Description: andrebrait commented on a change in pull request #254: URL: https://github.com/apache/commons-compress/pull/254#discussion_r828685900 ## File path: src/main/java/org/apache/commons/compress/archivers/tar/TarConstants.java ## @@ -227,6 +227,13 @@ */ byte LF_OLDNORM = 0; +/** + * Offset inside the header for the "link flag" field. + * + * @since 1.22 + */ +intLF_OFFSET = 156; Review comment: I'm just using the same style of the surrounding code. It looks better, unless I also remove spaces from everything else. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 742921) Time Spent: 1h (was: 50m) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 1h > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[
https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=742717&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-742717
]
ASF GitHub Bot logged work on COMPRESS-612:
---
Author: ASF GitHub Bot
Created on: 16/Mar/22 19:34
Start Date: 16/Mar/22 19:34
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #254:
URL: https://github.com/apache/commons-compress/pull/254#discussion_r828374324
##
File path:
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveOutputStream.java
##
@@ -624,11 +635,48 @@ private void addPaxHeaderForBigNumber(final Map paxHeaders,
}
}
+private void addFileTimePaxHeaderForBigNumber(final Map
paxHeaders,
+final String header, final FileTime value,
+final long maxValue) {
+if (value != null) {
+Instant instant = value.toInstant();
+long seconds = instant.getEpochSecond();
+int nanos = instant.getNano();
+if (nanos == 0) {
+addPaxHeaderForBigNumber(paxHeaders, header, seconds,
maxValue);
+} else {
+addInstantPaxHeader(paxHeaders, header, seconds, nanos);
+}
+}
+}
+
+private void addFileTimePaxHeader(final Map paxHeaders,
+final String header, final FileTime value) {
+if (value != null) {
+Instant instant = value.toInstant();
Review comment:
Use final where possible.
##
File path:
src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveEntryTest.java
##
@@ -306,6 +308,164 @@ public void
getOrderedSparseHeadersRejectsStructsPointingBeyondOutputEntry() thr
te.getOrderedSparseHeaders();
}
+@Test
+public void shouldParseTimePaxHeadersAndNotCountAsExtraPaxHeaders() {
+TarArchiveEntry entry = createEntryForTimeTests();
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("size", entry.getExtraPaxHeader("size"));
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("size", entry.getSize(), 1);
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03.599853900Z")),
entry.getLastModifiedTime());
+assertEquals("atime",
FileTime.from(Instant.parse("2022-03-14T01:31:00.706927200Z")),
entry.getLastAccessTime());
+assertEquals("ctime",
FileTime.from(Instant.parse("2022-03-14T01:28:59.700505300Z")),
entry.getStatusChangeTime());
+assertEquals("birthtime",
FileTime.from(Instant.parse("2022-03-14T01:29:00.723509000Z")),
entry.getCreationTime());
+}
+
+@Test
+public void shouldNotWriteTimePaxHeadersByDefault() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
+final TarArchiveOutputStream tos = new TarArchiveOutputStream(bos);
+tos.putArchiveEntry(entry);
+tos.write('W');
+tos.closeArchiveEntry();
+tos.close();
+
+final TarArchiveInputStream tis = new TarArchiveInputStream(new
ByteArrayInputStream(bos.toByteArray()));
+entry = tis.getNextTarEntry();
+assertNotNull("couldn't get entry", entry);
+
+assertEquals("extra header count", 0,
entry.getExtraPaxHeaders().size());
+assertNull("mtime", entry.getExtraPaxHeader("mtime"));
+assertNull("atime", entry.getExtraPaxHeader("atime"));
+assertNull("ctime", entry.getExtraPaxHeader("ctime"));
+assertNull("birthtime",
entry.getExtraPaxHeader("LIBARCHIVE.creationtime"));
+assertEquals("mtime",
FileTime.from(Instant.parse("2022-03-14T01:25:03Z")),
entry.getLastModifiedTime());
+assertNull("atime", entry.getLastAccessTime());
+assertNull("ctime", entry.getStatusChangeTime());
+assertNull("birthtime", entry.getCreationTime());
+
+assertEquals('W', tis.read());
+assertTrue("should be at end of entry", tis.read() < 0);
+
+assertNull("should be at end of file", tis.getNextTarEntry());
+tis.close();
+}
+
+@Test
+public void shouldWriteTimesForStarMode() throws IOException {
+TarArchiveEntry entry = createEntryForTimeTests();
+
+final ByteArrayOutputStream bos = new ByteArrayOutputStream();
+final TarArchiveOutputStream tos = new TarArchiveOutputStream(bos);
+tos.setBigNumberMode(TarArchiveOutputStream.BIGNUMBER_STAR);
+tos.putArchiveEntry(entry);
+tos.write('W');
+tos.closeArchiveEntry();
+tos.close(
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=741727&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-741727 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 15/Mar/22 16:23 Start Date: 15/Mar/22 16:23 Worklog Time Spent: 10m Work Description: andrebrait commented on pull request #254: URL: https://github.com/apache/commons-compress/pull/254#issuecomment-1068187687 @PeterAlfredLee Thanks, I checked it and I found the reason. It's because I removed this: ```java /** Convert millis to seconds */ public static final int MILLIS_PER_SECOND = 1000; ``` I put it back. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 741727) Time Spent: 40m (was: 0.5h) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 40m > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=741384&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-741384 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 15/Mar/22 01:10 Start Date: 15/Mar/22 01:10 Worklog Time Spent: 10m Work Description: PeterAlfredLee commented on pull request #254: URL: https://github.com/apache/commons-compress/pull/254#issuecomment-1067458816 Hi @andrebrait Thank you for your contributing. IIRC there's a japicmp report in generated target directory(/target/japicmp/japicmp.html). You can check it for detailed information. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 741384) Time Spent: 0.5h (was: 20m) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 0.5h > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=741034&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-741034 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 14/Mar/22 17:17 Start Date: 14/Mar/22 17:17 Worklog Time Spent: 10m Work Description: andrebrait commented on pull request #254: URL: https://github.com/apache/commons-compress/pull/254#issuecomment-1067083237 I'm also looking into feedback on why I'm getting this breakage. The checker says there's some method that does not throw a checked exception anymore, but I can't seem to find what's causing that. I haven't changed the signature of any methods in that way as far as checked exceptions go. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 741034) Time Spent: 20m (was: 10m) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 20m > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=741032&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-741032 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 14/Mar/22 17:10 Start Date: 14/Mar/22 17:10 Worklog Time Spent: 10m Work Description: andrebrait opened a new pull request #254: URL: https://github.com/apache/commons-compress/pull/254 R/W atime and ctime support for XSTAR/XUSTAR/POSIX R/W high precision (100ns increments) time support for POSIX Read support for atime and ctime for OLDGNU/GNU Use FileTime instead of Date to allow for higher precision Possible breaking change: `ctime` and `atime` are not part of the _**extra**_ PAX headers anymore. This means that, if anyone is using those manually, they won't be able to do that anymore. A possible solution would be to add them to the extra PAX headers anyway and update their values when setting the corresponding date fields. The other way around (updating the dates when setting the headers) is already working. Looking for feedback on that so I know if you think that's a problem or not. I'm als looking for feedback into possibly making BIGNUMBER_POSIX and possibly LONGNAME_POSIX the defaults, or at least having expand most errors related to big numbers to reference BIGNUMBER_POSIX and/or BIGNUMBER_GNU (although that's problematic for some TAR tools). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 741032) Remaining Estimate: 0h Time Spent: 10m > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 10m > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
