[jira] [Updated] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ 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/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/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|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/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 > - Ot
[jira] [Updated] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ 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/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. 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]- – 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/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
[jira] [Updated] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ 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/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. 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]- -- 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. > 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/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
[jira] [Updated] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andre Brait updated COMPRESS-612: - Summary: Support atime/ctime and higher time precision for TAR (was: Support modern TAR formats) > 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/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. -- This message was sent by Atlassian Jira (v8.20.1#820001)