[
https://issues.apache.org/jira/browse/COMPRESS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andre Brait updated COMPRESS-612:
---------------------------------
Description:
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/msg00001.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.
was:
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/msg00001.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|https://github.com/andrebrait/commons-compress/tree/feature/tarPaxHeaders].
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.
> 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
>
> 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/msg00001.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)
