[ https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16536739#comment-16536739 ]
ASF GitHub Bot commented on COMPRESS-459: ----------------------------------------- Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/67 [![Coverage Status](https://coveralls.io/builds/17891202/badge)](https://coveralls.io/builds/17891202) Coverage increased (+0.002%) to 86.355% when pulling **715352d3343358539a40b9623a9a00beb115ff30 on ctron:feature/fix_COMPRESS_459_1** into **f5330f7e667f5a7245c8a5f3007cda04554c5fe2 on apache:master**. > 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)