Description
This is a proposal for some code I have already worked on.
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 writtenLift 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.
Attachments
Issue Links
- is related to
-
COMPRESS-614 Use FileTime for time fields in SevenZipArchiveEntry
-
- Resolved
-
