[jira] [Closed] (VFS-666) Update Apache Commons Collections from 4.1 to 4.2.
[ https://issues.apache.org/jira/browse/VFS-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-666. Resolution: Fixed Fix Version/s: 2.2.1 In svn trunk. > Update Apache Commons Collections from 4.1 to 4.2. > -- > > Key: VFS-666 > URL: https://issues.apache.org/jira/browse/VFS-666 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.2.1 > > > Update Apache Commons Collections from 4.1 to 4.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-666) Update Apache Commons Collections from 4.1 to 4.2.
Gary Gregory created VFS-666: Summary: Update Apache Commons Collections from 4.1 to 4.2. Key: VFS-666 URL: https://issues.apache.org/jira/browse/VFS-666 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.2 Reporter: Gary Gregory Assignee: Gary Gregory Update Apache Commons Collections from 4.1 to 4.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BEANUTILS-510) Able to cause error 500 on any application running BeanUtils
Aaron created BEANUTILS-510:
---
Summary: Able to cause error 500 on any application running
BeanUtils
Key: BEANUTILS-510
URL: https://issues.apache.org/jira/browse/BEANUTILS-510
Project: Commons BeanUtils
Issue Type: Bug
Affects Versions: 1.9.3
Environment: *
Reporter: Aaron
By adding the characters ;?[ to the end of a URL (before URL parameters, if
there are any) on an application running BeanUtils, you are able to cause an
HTTP error 500 on the application. Here is the stack trace:
{{java.lang.IllegalArgumentException: Missing End Delimiter}}
{{ at
org.apache.commons.beanutils.expression.DefaultResolver.getIndex(DefaultResolver.java:90)}}
{{ at
org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:913)}}
{{ at
org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:823)}}
{{ at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:431)}}
{{ at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:493)}}
{{ at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:816)}}
{{ at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:203)}}
{{ at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)}}
{{ at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)}}
{{ at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)}}
{{ at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-460) ZstdCompressorOutputStream: specify compression level
[ https://issues.apache.org/jira/browse/COMPRESS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540469#comment-16540469 ] Gary Gregory commented on COMPRESS-460: --- PR welcome! :) > ZstdCompressorOutputStream: specify compression level > - > > Key: COMPRESS-460 > URL: https://issues.apache.org/jira/browse/COMPRESS-460 > Project: Commons Compress > Issue Type: Improvement > Components: Compressors >Affects Versions: 1.17 >Reporter: Carmi Grushko >Priority: Minor > Original Estimate: 5m > Remaining Estimate: 5m > > ZstdCompressorOutputStream allows to compress data using Zstandard, but the > default compression level of 3 is hard-coded. > Programs that wish to use a different compression level must reimplement > ZstdCompressorOutputStream. > I suggest we add a constructor that takes a compression level and passes it > to > `new ZstdOutputStream(...)`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COMPRESS-460) ZstdCompressorOutputStream: specify compression level
Carmi Grushko created COMPRESS-460: -- Summary: ZstdCompressorOutputStream: specify compression level Key: COMPRESS-460 URL: https://issues.apache.org/jira/browse/COMPRESS-460 Project: Commons Compress Issue Type: Improvement Components: Compressors Affects Versions: 1.17 Reporter: Carmi Grushko ZstdCompressorOutputStream allows to compress data using Zstandard, but the default compression level of 3 is hard-coded. Programs that wish to use a different compression level must reimplement ZstdCompressorOutputStream. I suggest we add a constructor that takes a compression level and passes it to `new ZstdOutputStream(...)`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540368#comment-16540368
]
ASF GitHub Bot commented on COMPRESS-459:
-
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/67
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
> Labels: patch-available
> Fix For: 1.18
>
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-459.
-
Resolution: Fixed
fixed in master, many thanks [~ctron]
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
> Labels: patch-available
> Fix For: 1.18
>
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540369#comment-16540369
]
ASF GitHub Bot commented on COMPRESS-459:
-
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/67
Many thanks!
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
> Labels: patch-available
> Fix For: 1.18
>
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540294#comment-16540294
]
ASF GitHub Bot commented on COMPRESS-459:
-
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/67
@ctron I've just started merging your changes locally
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
> Labels: patch-available
> Fix For: 1.18
>
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540049#comment-16540049
]
ASF GitHub Bot commented on COMPRESS-459:
-
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/67
`ZipEncoding` is a better choice for our internal use as it is used to
encode the name (and deals with "use null as the encoding to use the platform's
default encoding" transparently). You don't have to make the changes yourself
(but if you do, please add spaces around operators :-) ), but I won't complain
if you are faster than me.
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
> Labels: patch-available
> Fix For: 1.18
>
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539852#comment-16539852
]
ASF GitHub Bot commented on COMPRESS-459:
-
Github user ctron commented on the issue:
https://github.com/apache/commons-compress/pull/67
Yes, that might have been a solution as well. But I was thinking to use
something more Java-standard. If you want me to change this, I can do this as
well.
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
> Labels: patch-available
> Fix For: 1.18
>
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1403) DateUtils.truncate(Object date, int field) breaks Java type safety.
[ https://issues.apache.org/jira/browse/LANG-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539739#comment-16539739 ] Sebb commented on LANG-1403: Are we sure that the Object method is not useful? If we are, then I agree that deprecation would be a good first step, as at least there would be a warning at compile time. Removal would require a change of package name and Maven coords as well as major version change. > DateUtils.truncate(Object date, int field) breaks Java type safety. > --- > > Key: LANG-1403 > URL: https://issues.apache.org/jira/browse/LANG-1403 > Project: Commons Lang > Issue Type: Wish >Affects Versions: 3.7 >Reporter: Christian >Priority: Minor > > The DateUtils.truncate have three types of possible date input. > Calendar, Date, and Object. > The method which accept object as input is not necessary and will break the > type safety idea of java itself, so a wrong object will cause an runtime > exception and can't be found at compile time. > > Solution: > remove DateUtils.truncate(Object, int) method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-459:
Fix Version/s: 1.18
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
> Labels: patch-available
> Fix For: 1.18
>
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-459:
Component/s: (was: Compressors)
Archivers
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
> Labels: patch-available
> Fix For: 1.18
>
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-459:
Labels: patch-available (was: )
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
> Labels: patch-available
> Fix For: 1.18
>
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539723#comment-16539723
]
ASF GitHub Bot commented on COMPRESS-459:
-
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/67
Many thanks. We are not that squash-happy over here, two commits is fine.
I would have gone for `ZipEncoding` rather than `Charset` for consistency,
but can change that later myself, I really don't want to play "fetch me a rock"
here. Will merge the PR soonish.
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1403) DateUtils.truncate(Object date, int field) breaks Java type safety.
[ https://issues.apache.org/jira/browse/LANG-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539669#comment-16539669 ] Christian Kleinewaechter commented on LANG-1403: I agree that the overloaded methods with Object parameter provoke errors while giving very little value. Maybe deprecation could be an option? > DateUtils.truncate(Object date, int field) breaks Java type safety. > --- > > Key: LANG-1403 > URL: https://issues.apache.org/jira/browse/LANG-1403 > Project: Commons Lang > Issue Type: Wish >Affects Versions: 3.7 >Reporter: Christian >Priority: Minor > > The DateUtils.truncate have three types of possible date input. > Calendar, Date, and Object. > The method which accept object as input is not necessary and will break the > type safety idea of java itself, so a wrong object will cause an runtime > exception and can't be found at compile time. > > Solution: > remove DateUtils.truncate(Object, int) method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539652#comment-16539652
]
ASF GitHub Bot commented on COMPRESS-459:
-
Github user ctron commented on the issue:
https://github.com/apache/commons-compress/pull/67
Thanks @bodewig for reviewing this PR. Yes you are right, with everything
:wink:
I amended the PR, fixing the issues with the original PR and added the
functionality to the output stream as well. The made them two commits for to
easier understand what was fixed and what added. It can be squashed later on if
required.
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
