[
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062427#comment-16062427
]
Simon Spero commented on COMPRESS-400:
--------------------------------------
Just added a commit to remote abstracted support for extended attributes. The
commit message has some extended notes, which I am adding to the work log
should this need to be revisited (since a lot of this stuff is not documented
except in 'read the source code, not the spec'.
If this needs to be revisited, the following information is useful:
1. pax header keywords should be ascii.
star/gnutar (SCHILY.xattr.* ) do not check for this.
libarchive/bsdtar (LIBARCHIVE.xattr.*) use URL-Encoding.
2. pax header values should be encoded as UTF-8 characters (including \0).
star/gnutar (SCHILY.xattr.*) do not check for this.
libarchive/bsdtar (LIBARCHIVE.xattr.*) encode values using Base64.
libarchive/bsdtar will read SCHILY.xattr headers, but will not generate them.
gnutar will complain about LIBARCHIVE.xattr (and any other unknown) headers and
will neither encode nor decode them.
I believe that star is the same.
Proper support for handling extended attributes may require knowing which
convention should
be used on output. It may also require additional methods that handle byte[]
values appropriately.
Should Path based initalization of entry metadata be supported, it should be
noted that Java's abstraction of extended attributes treats handles them as
binary values (which must fit in a single ByteBuffer, and thus are of maximum
size MAX_INT). nio file attribute views may be a suitable basis handling
xattrs (and other related metadata).
https://docs.oracle.com/javase/7/docs/api/java/nio/file/attribute/UserDefinedFileAttributeView.html
> It should be possible for users to create and access extra PAX headers to tar
> archives
> ---------------------------------------------------------------------------------------
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
> Reporter: Simon Spero
> Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries. For
> example, a tar file containing maven artifacts could have extra headers
> carrying the groupid, artifactid, version, classifier, etc.
> If the appropriate prefixes are used, these headers can be extracted to posix
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra
> headers, plus modifications to the TarArchive*Stream to save unrecognized
> headers when reading, and to add any extra headers when writing.
> I have created a prototype implementation, but have not merged it into my
> fork of the project. I don't have full tests written, because I was using
> gnutar as an oracle.
> I have also ignored the issue of writing values to standard headers like
> size, though since the PAX specification states that doing things like
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm
> technically in compliance. The temptation is to do what was asked, then on
> close pop up a "Were you sure?" dialog, but that's mean. I guess I could use
> this to set the appropriate entry fields if doing so makes sense, but the
> easiest approach is to block setting any headers that would be consumed by
> the tar implementation when reading.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
