[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063085#comment-16063085
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user asfgit closed the pull request at:

https://github.com/apache/commons-compress/pull/31


> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063078#comment-16063078
 ] 

Stefan Bodewig commented on COMPRESS-400:
-

Thanks Simon, I've merged the PR.

Do you think your additional notes should go into the docs in some way? 
{{src/site/xdoc/tar.xml}} already contains information specific to tar support.

> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063074#comment-16063074
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user asfgit closed the pull request at:

https://github.com/apache/commons-compress/pull/46


> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062448#comment-16062448
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/46
  

[![Coverage 
Status](https://:/builds/12125302/badge)](https://:/builds/12125302)

Coverage increased (+0.1%) to 84.886% when pulling 
**8aeaa9c418862fc1d4fb4e166da72a2fac2493dc on sesuncedu:COMPRESS-400-squash** 
into **19e1b02f754a9b7bc969eb17bd52cc36a85c4d74 on apache:master**.



> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062446#comment-16062446
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

GitHub user sesuncedu opened a pull request:

https://github.com/apache/commons-compress/pull/46

COMPRESS-400 : Squashed version of  COMPRESS-400-REDUX.

Add support for extra PAX headers (local and global).
This PR has a single squash commit to simplify final  review
Signed-off-by: Simon Spero 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-400-squash

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/46.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #46


commit 8aeaa9c418862fc1d4fb4e166da72a2fac2493dc
Author: Simon Spero 
Date:   2017-06-25T22:28:07Z

COMPRESS-400 : Squash commit of COMPRESS-400-REDUX.

Add support for extra PAX headers (local and global).

Signed-off-by: Simon Spero 




> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062443#comment-16062443
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/31
  

[![Coverage 
Status](https://:/builds/12125243/badge)](https://:/builds/12125243)

Coverage increased (+0.1%) to 84.862% when pulling 
**daebf440f05432c00067e58074aa1922f5b80c8d on sesuncedu:COMPRESS-400-REDUX** 
into **19e1b02f754a9b7bc969eb17bd52cc36a85c4d74 on apache:master**.



> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062037#comment-16062037
 ] 

Stefan Bodewig commented on COMPRESS-400:
-

Let me retry, as I really like your changes and would like to merge them. I 
don't think we need {{addXattr}} and {{getXattr}} - and thus {{XATTR_PREFIX}}. 
They'd only ever be used by people who should know what they are doing and 
could add the prefixes themselves. They are convenience methods for an 
extremely small subset of our users that would be trivial to write outside of 
our code base.

I'd be happy to merge your change without these two methods.

> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050736#comment-16050736
 ] 

Stefan Bodewig commented on COMPRESS-400:
-

I see why one may want to specify xattrs, but do we really need to provide 
special methods for them?

> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050726#comment-16050726
 ] 

Simon Spero commented on COMPRESS-400:
--

If you have xattrs in the file system, and you tar with - - xattrs set,
they get added with that header by Gnu tar. Libarchive uses a different
prefix but reads both. Gnu tar complains if the libarchive headers are set.

There's some Extra Extended magic for names and values that I didn't code
up, because there are two sets of hacks that aren't standardized, and it's
only really important when extracting to the fs, but I left the tech debt.
Also, not sure if I want to handle binary values, but ought to. Annoyed
enough fixing  bugs in the  star mode base256 stuff :)

On Thu, Jun 15, 2017, 12:08 PM Stefan Bodewig (JIRA) 



> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050680#comment-16050680
 ] 

Stefan Bodewig commented on COMPRESS-400:
-

Thanks a lot Simon, the patch looks good.

Do you really think we need the special handling of {{SCHILY.xattr}}? I'd 
expect people who want to set those special attributes to know about the prefix 
and they could use {{get/setExtraPaxHeader}} themselves. Is setting those 
attributes such a common case for you (so far nobody has ever asked for being 
able to set PAX headers at all, so they don't seem to be used widely)?

> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048450#comment-16048450
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/31
  

[![Coverage 
Status](https://:/builds/11957185/badge)](https://:/builds/11957185)

Coverage increased (+0.1%) to 84.458% when pulling 
**bd44cb63b2198173c3529e2edd69ef123a8508f8 on sesuncedu:COMPRESS-400-REDUX** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048451#comment-16048451
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/31
  

[![Coverage 
Status](https://:/builds/11957185/badge)](https://:/builds/11957185)

Coverage increased (+0.1%) to 84.458% when pulling 
**bd44cb63b2198173c3529e2edd69ef123a8508f8 on sesuncedu:COMPRESS-400-REDUX** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048452#comment-16048452
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/31
  

[![Coverage 
Status](https://:/builds/11957185/badge)](https://:/builds/11957185)

Coverage increased (+0.1%) to 84.458% when pulling 
**bd44cb63b2198173c3529e2edd69ef123a8508f8 on sesuncedu:COMPRESS-400-REDUX** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048448#comment-16048448
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/31
  

[![Coverage 
Status](https://:/builds/11956800/badge)](https://:/builds/11956800)

Coverage increased (+0.1%) to 84.458% when pulling 
**ec06015710fc179ba58a546d02e6935d20825681 on sesuncedu:COMPRESS-400-REDUX** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048310#comment-16048310
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/31
  

[![Coverage 
Status](https://coveralls.io/builds/11955168/badge)](https://coveralls.io/builds/11955168)

Coverage decreased (-0.02%) to 84.322% when pulling 
**afabb743836b2b21bea67301f20c25b15e95865c on sesuncedu:COMPRESS-400-REDUX** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046910#comment-16046910
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/31
  

[![Coverage 
Status](https://coveralls.io/builds/11935842/badge)](https://coveralls.io/builds/11935842)

Coverage decreased (-0.03%) to 84.306% when pulling 
**3a1d29e2474519c3930742cf3000b6323bb426a8 on sesuncedu:COMPRESS-400-REDUX** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046902#comment-16046902
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user sesuncedu closed the pull request at:

https://github.com/apache/commons-compress/pull/27


> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046898#comment-16046898
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

GitHub user sesuncedu opened a pull request:

https://github.com/apache/commons-compress/pull/31

COMPRESS-400 It should be possible for users to create and access extra PAX 
headers to tar archives

Add extra header map to tar archive entry.
Move PAX header processing code from TarArchiveInputStream to 
TarAchiveEntry.
Use same code for processing user supplied extra headers - thus setting 
"size "changes the value of getSize().
Add any extra PAX headers to output map when putting entry in 
TarArchiveOutputStream.
Add simple tests for getting/setting xattr, setting "size", and round 
tripping.

Signed-off-by: Simon Spero 

(cherry picked from commit 1d9b3c8)
Signed-off-by: Simon Spero 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-400-REDUX

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/31.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #31


commit 3a1d29e2474519c3930742cf3000b6323bb426a8
Author: Simon Spero 
Date:   2017-06-05T19:58:27Z

COMPRESS-400 It should be possible for users to create and access extra PAX 
headers to tar archives

Add extra header map to tar archive entry.
Move PAX header processing code from TarArchiveInputStream to 
TarAchiveEntry.
Use same code for processing user supplied extra headers - thus setting 
"size "changes the value of getSize().
Add any extra PAX headers to output map when putting entry in 
TarArchiveOutputStream.
Add simple tests for getting/setting xattr, setting "size", and round 
tripping.

Signed-off-by: Simon Spero 

(cherry picked from commit 1d9b3c8)
Signed-off-by: Simon Spero 




> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046661#comment-16046661
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user bodewig commented on the issue:

https://github.com/apache/commons-compress/pull/27
  
Thanks, do you think you could re-create the PR without the commits that 
belong to #26 ?


> 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)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16044686#comment-16044686
 ] 

Simon Spero commented on COMPRESS-400:
--

For 3, it looks TarArchiveInputStream looks like it's already doing the right 
thing
For 2, it looks quite doable.  I think that it's necessary to delay writing a 
global header block until  there's a request to write a regular entry, since it 
seems that you can't follow a global extended header with the end-of-archive 
record, despite it not being attached to any particular file. 



> 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.3.15#6346)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039474#comment-16039474
 ] 

Simon Spero commented on COMPRESS-400:
--

1. Should the appropriate method names be changed to from extra to either ext 
or extended? I was thinking of them as extra (to the ones already processed), 
and so mentally expanded exthdr to extra, contra PAX regem. 

2. Should I add methods to TarArchiveOutputStream to allow setting global 
extended headers to be emitted in a global header record when the next header 
set is pushed?

3. Should I change TarArchiveInputStream to propagate  input global extended 
header values to each entry?

> 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.3.15#6346)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037503#comment-16037503
 ] 

Simon Spero commented on COMPRESS-400:
--

I realized that "hey, there's code that already exists to set the fields in a 
TarArchiveEntry from special Pax Headers", so I moved the functionality from 
the InputStream to the Entry, and setting "size" et. al. work as expected. 

I'm not sure if this is the right time to do ctime and atime?

> 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.3.15#6346)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037491#comment-16037491
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

GitHub user sesuncedu opened a pull request:

https://github.com/apache/commons-compress/pull/27

COMPRESS-400 

Add extra header map to tar archive entry.
Move PAX header processing code from TarArchiveInputStream to 
TarAchiveEntry.
Use same code for processing user supplied extra headers - thus setting 
"size "changes the value of getSize().
Add any extra PAX headers to output map when putting entry in 
TarArchiveOutputStream.
Add simple tests for getting/setting xattr, setting "size", and round 
tripping.

This PR uses COMPRESS-399 as a base.  
To make it easier to cherry-pick + rebase the PR has been split in two.

 1d9b3c88455caceca81f0ff6b7eca0958c631359 contains just the code changes 
and test changes,  and does not bump the minor package version .  This will 
cause the bundle:baseline verify goal in 399 to  break the build.

82405c13bd2688817108d3f2854387b3417a764d  increases the package minor 
version to the correct value



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-400

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/27.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #27


commit 109b14915cf594e5c2031e58d6f2fd0595fc184f
Author: Simon Spero 
Date:   2017-06-02T17:25:02Z

COMPRESS-399 OSGI package versions are overly pessimistic, except when 
they're overly optimisic

Add packageinfo files for per-package version settings. Initialize to 1.14
Copy packageinfo files in resource phase.

Use latest bundle plugin.
Remove superflous headers from manifest.
Pretty-print the manifest.
Add bundle:baseline to the verify phase
Add bundle:baseline-report to the site phase
To change the base version from default (i.e. previous release) set 
comparisonVersion property

Change travis build goal to verify

Signed-off-by: Simon Spero 

commit 3653a2e19b51c9bd894e3928ed959c0132afd9b6
Author: Simon  Spero 
Date:   2017-06-02T17:37:53Z

Default rat doesn't ignore packageinfo

One line of non copyrightable material does not need the license header  :)

commit 27b65778eee34805838a0e43777b98fb6714dc2a
Author: Simon Spero 
Date:   2017-06-05T15:55:18Z

Replace packageinfo files with annotated package-info.java as source of 
version info.
Add build time dependency on org,osgi.annotation for Version annotation.
Remove resource copy.

Signed-off-by: Simon Spero 

commit 1d9b3c88455caceca81f0ff6b7eca0958c631359
Author: Simon Spero 
Date:   2017-06-05T19:58:27Z

COMPRESS-400 It should be possible for users to create and access extra PAX 
headers to tar archives

Add extra header map to tar archive entry.
Move PAX header processing code from TarArchiveInputStream to 
TarAchiveEntry.
Use same code for processing user supplied extra headers - thus setting 
"size "changes the value of getSize().
Add any extra PAX headers to output map when putting entry in 
TarArchiveOutputStream.
Add simple tests for getting/setting xattr, setting "size", and round 
tripping.

This PR uses COMPRESS-399 as a base.  To make it easier to cherry-pick, 
this commit does not bump the minor
package version;  this will cause the baseline verify stage in 399 to  
break the build, since the API has changed in a backwards compatible fashion

A separate commit increases the package minor version.

Signed-off-by: Simon Spero 

commit 82405c13bd2688817108d3f2854387b3417a764d
Author: Simon Spero 
Date:   2017-06-05T20:02:32Z

Increase the minor package version for
org.apache.commons.compress.archivers.tar to 1.15.0 to reflect
backwards compatible changes to API:

[INFO] < org.apache.commons.compress.archivers.tar  minor  
1.15.0 1.14.0 1.15.0 -
[INFO]  < class 
org.apache.commons.compress.archivers.tar.TarArchiveEntry
[INFO]  + method addPaxHeader(java.lang.String,java.lang.String)
[INFO]  + method addXattr(java.lang.String,java.lang.String)
[INFO]  + method clearExtraPaxHeaders()
[INFO]  + method getExtraPaxHeader(java.lang.String)
[INFO]  + return java.lang.String
[INFO]  + method getExtraPaxHeaders()
[INFO]  + return 

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034302#comment-16034302
 ] 

Stefan Bodewig commented on COMPRESS-400:
-

Sounds like a good idea.

We could try to prevent people from setting headers that might be set by our 
output stream itself (path, linkpath, size, gid, mtime, uid, mode, 
SCHILY.devmajor and SCHILY.devminor as of 1.14) but I'm not sure this is worth 
the effort. If people really want to set those values themselves, they should 
get what they want IMHO.

> 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.3.15#6346)