[jira] [Updated] (COMPRESS-612) Support modern TAR formats
[ 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/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/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. 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/msg1.html - 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 - 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/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 modern TAR formats > -- > > 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/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 inte
[jira] [Updated] (COMPRESS-612) Support modern TAR formats
[ 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/msg1.html - 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 - 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/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. 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. - 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 - 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/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 modern TAR formats > -- > > 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/msg1.html > - 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 > - 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/feature/tarPaxHeaders]. > Since compatibility with Android now requires API
[jira] [Updated] (COMPRESS-612) Support modern TAR formats
[ 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. - 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 - 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/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. 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 bigger files are fully supported by some TAR archiving tools such as GNU TAR. - 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 - 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/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 modern TAR formats > -- > > 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. > - 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 > - 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/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. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (COMPRESS-612) Support modern TAR formats
[ 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 bigger files are fully supported by some TAR archiving tools such as GNU TAR. - 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 - 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/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. 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 2GB. This limitation was lifted as of POSIX.1-2001 and bigger files are fully supported by some TAR archiving tools such as GNU TAR. - 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 - 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 2GB limit when using BIGNUMBER_POSIX_2001 I already have some code for that in [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 modern TAR formats > -- > > 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 bigger files are fully supported by some TAR archiving tools such as GNU > TAR. > - 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 > - 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/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. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (COMPRESS-612) Support modern TAR formats
[ 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 2GB. This limitation was lifted as of POSIX.1-2001 and bigger files are fully supported by some TAR archiving tools such as GNU TAR. - 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 - 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 2GB limit when using BIGNUMBER_POSIX_2001 I already have some code for that in [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. 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 2GB. This limitation was lifted as of POSIX.1-2001 and bigger files are fully supported by some TAR archiving tools such as GNU TAR. - 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 - Lift the 2GB limit - Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for the bigger size, mtime, ctime and atime to be written I already have some code for that in 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 modern TAR formats > -- > > 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 2GB. This limitation was lifted as of POSIX.1-2001 > and bigger files are fully supported by some TAR archiving tools such as GNU > TAR. > - 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 > - 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 2GB limit when using BIGNUMBER_POSIX_2001 > I already have some code for that in > [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. -- This message was sent by Atlassian Jira (v8.20.1#820001)
