[jira] [Commented] (COMPRESS-555) ZipArchiveInputStream should allow stored entries with data descriptor by default
[
https://issues.apache.org/jira/browse/COMPRESS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194010#comment-17194010
]
Stefan Bodewig commented on COMPRESS-555:
-
Unfortunately trying to read STORED entries that use a data descriptor is
unreliable to say the least. It is very easy to do if you can read the central
directory at the end of the archive - and thus ZipFile handles them just fine,
but reading the archive as a stream is a very different issue.
The default right now will tell you "I don't think I can handle this entry" if
you use the {{canReadEntryData}} method. The non-default option will read
forward until it finds something that looks like the signature of the next ZIP
entry. This will completely break down if the STORED entry contains such a
sequence of bytes - ZIPs in ZIPs is the primary example for this (think WARs
containing JARs for example). In recent versions we'll try to verify the
claimed size we read from what we believe to be the data descriptor matches the
length we've read, but then you are faced with an IOException for reading an
entry that the stream claimed to be able to handle.
Personally I believe the option will lead to too much confusion to enable it by
default. I prefer to have users take the deliberate choice and realize what
they are signing up for. Even better they would find a way to make the initial
stream seekable and use Zipfile rather than ZipArchiveInputStream.
> ZipArchiveInputStream should allow stored entries with data descriptor by
> default
> -
>
> Key: COMPRESS-555
> URL: https://issues.apache.org/jira/browse/COMPRESS-555
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Trevor Bentley
>Priority: Major
> Fix For: 1.21
>
>
> We are currently using tika for text extraction which uses commons-compress
> for handling zips. Currently some sites are returning zips that have entries
> with stored data descriptors which fail to extract due to the
> ZipArchiveInputStream defaulting to false for
> 'allowStoredEntriesWithDataDescriptor'.
> Allowing the reading of stored entries on Zip archives should be enabled by
> default.
> PR: https://github.com/apache/commons-compress/pull/137
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-vfs] dependabot[bot] opened a new pull request #127: Bump exec-maven-plugin from 1.6.0 to 3.0.0
dependabot[bot] opened a new pull request #127:
URL: https://github.com/apache/commons-vfs/pull/127
Bumps [exec-maven-plugin](https://github.com/mojohaus/exec-maven-plugin)
from 1.6.0 to 3.0.0.
Release notes
Sourced from https://github.com/mojohaus/exec-maven-plugin/releases;>exec-maven-plugin's
releases.
exec-maven-plugin-3.0.0
Bug Fixes
Resolving target dir via
${project.build.directory}, so to make s… https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/124;>#124
Ensure mojo descriptors are extracted after compilation https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/123;>#123
Argument file for modulepath is generated wrongly when paths contains
spaces https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/115;>#115
java.lang.String cannot be cast to org.codehaus.mojo.exec.Modulepath https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/75;>#75
⭐ Enhancement
Resolves https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/152;>#152
- Adds option to redirect program output of exec:exec to the maven logger. https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/153;>#153
Program output can be difficult to trace and may be jumbled with Maven
logs when running Maven with multiple threads https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/152;>#152
Fix type in Property.java https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/147;>#147
Correct spelling and remove redundant small https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/142;>#142
Fix typo https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/140;>#140
timeout configuration parameter https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/128;>#128
Methodhandles https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/119;>#119
Introduce Mock Repository Manager https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/117;>#117
Improved docs about environmentVariables/ config of exec:exec
goal https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/104;>#104
Add CodeTriage badge to mojohaus/exec-maven-plugin https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/pull/96;>#96
[Enhancement] Support for JPMS module path for exec:java https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/90;>#90
:heart: Contributors
We'd like to thank all the contributors who worked on this release!
https://github.com/elharo;>@elharo
https://github.com/britter;>@britter
https://github.com/stokito;>@stokito
https://github.com/hankolerd;>@hankolerd
https://github.com/rfscholte;>@rfscholte
https://github.com/gaurav9822;>@gaurav9822
https://github.com/codetriage-readme-bot;>@codetriage-readme-bot
Commits
https://github.com/mojohaus/exec-maven-plugin/commit/9705839246711bd375bf7712df05c621b168fbb1;>9705839
[maven-release-plugin] prepare release exec-maven-plugin-3.0.0
https://github.com/mojohaus/exec-maven-plugin/commit/66563e6891ce812a189d649352f4a0ac95e57050;>66563e6
get this working with java11
https://github.com/mojohaus/exec-maven-plugin/commit/13d1369e039f0f75e2d565a903368dbd5b2c20af;>13d1369
Merge pull request https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/153;>#153
from hankolerd/master
https://github.com/mojohaus/exec-maven-plugin/commit/7935062de951ab332cd50fbc05d8ab2070d2b205;>7935062
152 - Adds option to redirect program output of exec:exec to the maven
logger.
https://github.com/mojohaus/exec-maven-plugin/commit/dbe2c733dd3ae9728ac35f76ec05472444e7b13e;>dbe2c73
use mojo parent 50
https://github.com/mojohaus/exec-maven-plugin/commit/c7c3fe36232003f19d8e5d2109e4f7ab4f3c4546;>c7c3fe3
Merge pull request https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/142;>#142
from elharo/patch-1
https://github.com/mojohaus/exec-maven-plugin/commit/1bb783822860c78e9daf8c7155f3ad2d1814a51d;>1bb7838
Merge pull request https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/140;>#140
from britter/patch-1
https://github.com/mojohaus/exec-maven-plugin/commit/0a9b9cb33a0aa3062c258c695af4eed6fea72f22;>0a9b9cb
Merge pull request https://github-redirect.dependabot.com/mojohaus/exec-maven-plugin/issues/147;>#147
from gaurav9822/master
https://github.com/mojohaus/exec-maven-plugin/commit/581e6ed87b1e4ac3d9fa0abdab85275d60983626;>581e6ed
Added OpenJDK 14
https://github.com/mojohaus/exec-maven-plugin/commit/52d75dc2744669e76f568759df6ba34f6d308aaa;>52d75dc
Update Property.java
Additional commits viewable in https://github.com/mojohaus/exec-maven-plugin/compare/exec-maven-plugin-1.6.0...exec-maven-plugin-3.0.0;>compare
view
[![Dependabot
[GitHub] [commons-vfs] dependabot[bot] opened a new pull request #128: Bump commons-net from 3.6 to 3.7
dependabot[bot] opened a new pull request #128: URL: https://github.com/apache/commons-vfs/pull/128 Bumps commons-net from 3.6 to 3.7. [](https://docs.github.com/en/github/managing-security-vulnerabilities/configuring-github-dependabot-security-updates) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] dependabot[bot] opened a new pull request #126: Bump slf4j-api from 1.7.26 to 1.7.30
dependabot[bot] opened a new pull request #126: URL: https://github.com/apache/commons-vfs/pull/126 Bumps [slf4j-api](https://github.com/qos-ch/slf4j) from 1.7.26 to 1.7.30. Commits https://github.com/qos-ch/slf4j/commit/0b97c416e42a184ff9728877b461c616187c58f7;>0b97c41 move to 1.7.30 https://github.com/qos-ch/slf4j/commit/c6c7a98a7ee1e71382348ae3e41ff7818dfafd65;>c6c7a98 fix SLF4J-469 https://github.com/qos-ch/slf4j/commit/ca93154c79d7489ccc36a6957ebc2e74c34181ba;>ca93154 do not deploy slf4j-site https://github.com/qos-ch/slf4j/commit/d061e25477fa6928fbe1290a200c9a3442156b2b;>d061e25 this module is Apache 2.0 licensed https://github.com/qos-ch/slf4j/commit/e8ce694e2e05999185479875e9f93aeaf7570b99;>e8ce694 preapre release 1.7.29 https://github.com/qos-ch/slf4j/commit/125e7cca190c48fedcb92f377fd7361661f7537c;>125e7cc Merge pull request https://github-redirect.dependabot.com/qos-ch/slf4j/issues/219;>#219 from delgurth/1.7-maintenance-with-slf4j-466 https://github.com/qos-ch/slf4j/commit/a7562cb4b928c225192405b4d849246db60107d4;>a7562cb SLF4J-466: backport changes to 1.7 https://github.com/qos-ch/slf4j/commit/9752c892fdf4d9d13ea020ac95fca2284ccbf68e;>9752c89 specify jdk8 in travis https://github.com/qos-ch/slf4j/commit/b44fbd53cc8bc87f40e5412e60495b19bbf07bb0;>b44fbd5 prepare release 1.7.28 https://github.com/qos-ch/slf4j/commit/2a1374691f394b85b7da4a98d2b61105ba19e1b1;>2a13746 correct Automatic-Module-Name: org.apache.log4j Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.26...v_1.7.30;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/configuring-github-dependabot-security-updates) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] PeterAlfredLee commented on pull request #137: Compress-555 allow reading of stored entries in zips by default
PeterAlfredLee commented on pull request #137: URL: https://github.com/apache/commons-compress/pull/137#issuecomment-690835644 Some explanizations for the `allowStoredEntriesWithDataDescriptor`: An entry using STORED method means it would not use any compression - it's just a memcopy. For most of time, the size and compressed size(they are equal in the case of STORED) are stored in the Local File Header - which locates before the file raw data. So we can directly read the accurate amout of bytes, because we already know the amout of data before we start to extract the file. This changes if the entry is using STORED and data descriptor at the same time. The size and compressed size is stored in the data descriptor, and the data descriptor locates after the raw file data. With data descriptor, we do not know the size of the file before we start to extract the file. We do not know the accurate size of data before we start extracting file, so we need to check if a signature(signature of Local File Header, Central Directory Record or Data Descriptor) is met byte by byte. Obviously, it is slower if the data descriptor is used for STORED. What's worse, there are some cases lead to a error extracting : some bytes in the raw file data may equal to signature, and compress will stop reading at a wrong location. This is mostly happened in a zip archive that contains another zip archive. And wo do not have any workaround here. In short words, setting `allowStoredEntriesWithDataDescriptor` to be true for STROED entries would lead to a slower extraction, and for some times it would lead to a failed extraction(e.g. zip archive in zip). That's why we use `allowStoredEntriesWithDataDescriptor` and the default value is false. This may be a little complicated, but I hope it helps. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #102: Bump sshd-core from 0.8.0 to 2.5.1
garydgregory commented on pull request #102: URL: https://github.com/apache/commons-vfs/pull/102#issuecomment-690814371 @dependabot rebase This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory merged pull request #112: Bump mina-core from 2.0.20 to 2.1.4
garydgregory merged pull request #112: URL: https://github.com/apache/commons-vfs/pull/112 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory merged pull request #103: Bump hadoop.version from 3.2.1 to 3.3.0
garydgregory merged pull request #103: URL: https://github.com/apache/commons-vfs/pull/103 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #117: VFS-782 - pass correct proxy authentication credentials
garydgregory commented on pull request #117: URL: https://github.com/apache/commons-vfs/pull/117#issuecomment-690797731 Hi @satish-csi You need better tests. The tests don't show that anything was fixed because they succeed when run without the changes to `src/main`. I expect: - Apply patch to `src/test` only - New tests fail - Apply remainder of the patch to `src/main` - All tests pass This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #112: Bump mina-core from 2.0.20 to 2.1.4
garydgregory commented on pull request #112: URL: https://github.com/apache/commons-vfs/pull/112#issuecomment-690794775 @dependabot rebase This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #103: Bump hadoop.version from 3.2.1 to 3.3.0
garydgregory commented on pull request #103: URL: https://github.com/apache/commons-vfs/pull/103#issuecomment-690794666 @dependabot rebase This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IO-686) IOUtils.toByteArray(InputStream) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193855#comment-17193855
]
Gary Gregory commented on IO-686:
-
In general, we make the Javadoc match the code, as the code evolves.
In this case, that method's Javadoc got out of sync with code. The
method is now used from other call sites where the expected result is
an empty byte array.
Gary
> IOUtils.toByteArray(InputStream) Javadoc does not match code
>
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
> Fix For: 2.9.0
>
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IO-686) IOUtils.toByteArray(InputStream) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193809#comment-17193809
]
Alan Moffat commented on IO-686:
[~ggregory] is this expected behaviour then? I ask as it's a bit of a breaking
change and I was expecting the javadoc to be right as that's how the previous
version worked. Your comment suggests that that the code is right and javadoc
is wrong which is surprising.
> IOUtils.toByteArray(InputStream) Javadoc does not match code
>
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
> Fix For: 2.9.0
>
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] garydgregory commented on pull request #137: Compress-555 allow reading of stored entries in zips by default
garydgregory commented on pull request #137: URL: https://github.com/apache/commons-compress/pull/137#issuecomment-690616016 Good find. Let's get some feedback from the community to learn if there are side-effects to worry about here. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] tbentleypfpt commented on pull request #137: Compress-555 allow reading of stored entries in zips by default
tbentleypfpt commented on pull request #137:
URL: https://github.com/apache/commons-compress/pull/137#issuecomment-690538513
> Sounds like tika needs to call the other constructor.
Well it goes through the ArchiveStreamFactory in commons-compress and there
is no way of passing in from tika whether we want to enable that feature or not
since it's specific to ZIP.
`@Override
public ArchiveInputStream createArchiveInputStream(final String
archiverName, final InputStream in,
final String actualEncoding) throws ArchiveException {
...
if (ZIP.equalsIgnoreCase(archiverName)) {
if (actualEncoding != null) {
return new ZipArchiveInputStream(in, actualEncoding);
}
return new ZipArchiveInputStream(in);
}
...`
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-compress] coveralls commented on pull request #137: Compress-555 allow reading of stored entries in zips by default
coveralls commented on pull request #137: URL: https://github.com/apache/commons-compress/pull/137#issuecomment-690534989 [](https://coveralls.io/builds/33368761) Coverage increased (+0.01%) to 87.231% when pulling **3c0ec254d96eda37053d0221759f5dc93195c38c on tbentleypfpt:COMPRESS-555-allow-stored-entries-in-zips-by-default** into **550e525749607ee14daa74a17f16acfa505c2b7e on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] garydgregory commented on pull request #137: Compress-555 allow reading of stored entries in zips by default
garydgregory commented on pull request #137: URL: https://github.com/apache/commons-compress/pull/137#issuecomment-690532770 Sounds like tika needs to call the other constructor. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMPRESS-555) ZipArchiveInputStream should allow stored entries with data descriptor by default
[ https://issues.apache.org/jira/browse/COMPRESS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Bentley updated COMPRESS-555: Description: We are currently using tika for text extraction which uses commons-compress for handling zips. Currently some sites are returning zips that have entries with stored data descriptors which fail to extract due to the ZipArchiveInputStream defaulting to false for 'allowStoredEntriesWithDataDescriptor'. Allowing the reading of stored entries on Zip archives should be enabled by default. PR: https://github.com/apache/commons-compress/pull/137 was: We are currently using tika for text extraction which uses commons-compress for handling zips. Currently some sites are returning zips that have entries with stored data descriptors which fail to extract due to the ZipArchiveInputStream defaulting to false for 'allowStoredEntriesWithDataDescriptor'. Allowing the reading of stored entries on Zip archives should be enabled by default. Example service creating zips with stored entries with data descriptor is Microsoft OneDrive. > ZipArchiveInputStream should allow stored entries with data descriptor by > default > - > > Key: COMPRESS-555 > URL: https://issues.apache.org/jira/browse/COMPRESS-555 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.20 >Reporter: Trevor Bentley >Priority: Major > Fix For: 1.21 > > > We are currently using tika for text extraction which uses commons-compress > for handling zips. Currently some sites are returning zips that have entries > with stored data descriptors which fail to extract due to the > ZipArchiveInputStream defaulting to false for > 'allowStoredEntriesWithDataDescriptor'. > Allowing the reading of stored entries on Zip archives should be enabled by > default. > PR: https://github.com/apache/commons-compress/pull/137 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] tbentleypfpt opened a new pull request #137: Compress-555 allow reading of stored entries in zips by default
tbentleypfpt opened a new pull request #137: URL: https://github.com/apache/commons-compress/pull/137 We are currently using tika for text extraction which uses commons-compress for handling zips. Currently some sites are returning zips that have entries with stored data descriptors which fail to extract due to the ZipArchiveInputStream defaulting to false for 'allowStoredEntriesWithDataDescriptor'. This PR adjusts the ZipArchiveInputStream to allow reading of stored entries with data descriptor by default. https://issues.apache.org/jira/browse/COMPRESS-555 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMPRESS-555) ZipArchiveInputStream should allow stored entries with data descriptor by default
[ https://issues.apache.org/jira/browse/COMPRESS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Bentley updated COMPRESS-555: Description: We are currently using tika for text extraction which uses commons-compress for handling zips. Currently some sites are returning zips that have entries with stored data descriptors which fail to extract due to the ZipArchiveInputStream defaulting to false for 'allowStoredEntriesWithDataDescriptor'. Allowing the reading of stored entries on Zip archives should be enabled by default. Example service creating zips with stored entries with data descriptor is Microsoft OneDrive. was:Allowing the reading of stored entries on Zip archives should be enabled by default. > ZipArchiveInputStream should allow stored entries with data descriptor by > default > - > > Key: COMPRESS-555 > URL: https://issues.apache.org/jira/browse/COMPRESS-555 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.20 >Reporter: Trevor Bentley >Priority: Major > Fix For: 1.21 > > > We are currently using tika for text extraction which uses commons-compress > for handling zips. Currently some sites are returning zips that have entries > with stored data descriptors which fail to extract due to the > ZipArchiveInputStream defaulting to false for > 'allowStoredEntriesWithDataDescriptor'. > Allowing the reading of stored entries on Zip archives should be enabled by > default. > Example service creating zips with stored entries with data descriptor is > Microsoft OneDrive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-686) IOUtils.toByteArray(null) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-686:
---
Summary: IOUtils.toByteArray(null) Javadoc does not match code (was:
[v2.8.0] IOUtils.toByteArray(null) Javadoc does not match code)
> IOUtils.toByteArray(null) Javadoc does not match code
> -
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IO-686) IOUtils.toByteArray(InputStream) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-686.
Fix Version/s: 2.9.0
Resolution: Fixed
> IOUtils.toByteArray(InputStream) Javadoc does not match code
>
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
> Fix For: 2.9.0
>
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-686) IOUtils.toByteArray(InputStream) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-686:
---
Summary: IOUtils.toByteArray(InputStream) Javadoc does not match code
(was: IOUtils.toByteArray(null) Javadoc does not match code)
> IOUtils.toByteArray(InputStream) Javadoc does not match code
>
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-592) Modified FileUtilsDirectoryContainsTestCase File
[ https://issues.apache.org/jira/browse/IO-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-592: --- Fix Version/s: (was: 2.8.0) 2.9.0 > Modified FileUtilsDirectoryContainsTestCase File > > > Key: IO-592 > URL: https://issues.apache.org/jira/browse/IO-592 > Project: Commons IO > Issue Type: Task > Components: Utilities >Reporter: sangwoo son >Priority: Minor > Fix For: 2.9.0 > > Time Spent: 10m > Remaining Estimate: 0h > > * no test code for when directory is null in directoryContains method > * I think the validation phase of the test case that generates the exception > is not correct > send > I'll send pull request > please review > thanks :) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-555) Add a FileSystem enum to provide legal file names
[
https://issues.apache.org/jira/browse/IO-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-555:
---
Fix Version/s: (was: 2.8.0)
2.9.0
> Add a FileSystem enum to provide legal file names
> -
>
> Key: IO-555
> URL: https://issues.apache.org/jira/browse/IO-555
> Project: Commons IO
> Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.9.0
>
>
> Add {{org.apache.commons.io.FilenameUtils.isIllegalWindowsFileName(char)}}.
> {code:java}
> /**
> * Checks whether the given character is illegal in a Windows file names.
> *
> * The illegal character are:
> *
> *
> * < (less than
> * > (greater than
> * : (colon
> * " (double quote
> * / (forward slash
> * \ (backslash
> * | (vertical bar or pipe
> * ? (question mark
> * * (asterisk
> * ASCII NUL (0)
> * Integer characters 1 through 31
> * There may be other characters that the file name does not allow.
> Please see
> * href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx">Naming
> Files, Paths,
> * and Namespaces
> *
> *
> * @see href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx">Naming
> Files,
> * Paths, and Namespaces
> * @param c
> *the character to check
> * @return whether the give character is legal
> * @since 2.7
> */
> {code}
> I use this method as a building block to create file names based on Strings
> from other sources.
> A further contribution could be: {{String toLegalWindowsFileName(String
> input, char replacementChar)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-686) [v2.8.0] IOUtils.toByteArray(null) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-686:
---
Affects Version/s: 2.8.0
> [v2.8.0] IOUtils.toByteArray(null) Javadoc does not match code
> --
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-568) AutoCloseInputStream sometimes breaks mark/reset contract
[
https://issues.apache.org/jira/browse/IO-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-568:
---
Fix Version/s: (was: 2.8.0)
2.9.0
> AutoCloseInputStream sometimes breaks mark/reset contract
> -
>
> Key: IO-568
> URL: https://issues.apache.org/jira/browse/IO-568
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Thomas Mortagne
>Priority: Minor
> Fix For: 2.9.0
>
>
> If the the inputstream support mark it should switch back from
> ClosedInputStream to initial InputStream and call reset on it.
> To reproduce:
> {code}
> AutoCloseInputStream stream = new AutoCloseInputStream(new
> ByteArrayInputStream("toto".getBytes()));
> stream.mark("toto".length());
> while (stream.read(new byte[1]) != -1);
> stream.reset();
> {code}
> Among other things it's causing TIKA-2395.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-584) Add a module info descriptor
[ https://issues.apache.org/jira/browse/IO-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-584: --- Fix Version/s: (was: 2.8.0) 2.9.0 > Add a module info descriptor > > > Key: IO-584 > URL: https://issues.apache.org/jira/browse/IO-584 > Project: Commons IO > Issue Type: Improvement > Components: Filters, Streams/Writers, Utilities >Affects Versions: 2.6 >Reporter: Jeff Gullett >Priority: Minor > Fix For: 2.9.0 > > > Since commons-io is an automatic module, clients are unable to run jlink > against anything that is dependent upon it. Add a module-info.java file, in > order enable using jlink with commons-io. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-685) LineReader to implement AutoCloseable
[
https://issues.apache.org/jira/browse/IO-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-685:
---
Fix Version/s: (was: 2.8.0)
2.9.0
> LineReader to implement AutoCloseable
> -
>
> Key: IO-685
> URL: https://issues.apache.org/jira/browse/IO-685
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.7
>Reporter: Andrea Rombaldi
>Priority: Minor
> Fix For: 3.x, 2.9.0
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> org.apache.commons.io.LineReader should implement the AutoCloseable interface
> in order to allow the use of try-with-resources statement such as in the
> following example:
> {{try (final LineIterator itr = new LineIterator(new
> FileReader("c:/temp/readme.txt"))) {}}
> {{ while (itr.hasNext()) {}}
> {{ System.out.println(itr.next());}}
> }
> }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-678) FileUtils.copyFile does not maintain file permissions
[ https://issues.apache.org/jira/browse/IO-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-678: --- Fix Version/s: (was: 2.8.0) 2.9.0 > FileUtils.copyFile does not maintain file permissions > - > > Key: IO-678 > URL: https://issues.apache.org/jira/browse/IO-678 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.7 >Reporter: Jorge >Priority: Major > Fix For: 2.9.0 > > Attachments: FileUtilsCopyDirectoryToDirectoryTestCase.java > > > I found that permissions (specifically, execute) are not maintained when > using FileUtils.copyFile. The attached test demonstrates the behavior. > > With version 2.6 the following permissions are obtained: > [OTHERS_READ, OWNER_READ, OWNER_WRITE, GROUP_READ, GROUP_WRITE] > > while with version 2.7: > [OWNER_READ, OWNER_WRITE] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-686) [v2.8.0] IOUtils.toByteArray(null) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193677#comment-17193677
]
Gary D. Gregory commented on IO-686:
I'll update the Javadoc to match the code.
> [v2.8.0] IOUtils.toByteArray(null) Javadoc does not match code
> --
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Reporter: Alan Moffat
>Priority: Critical
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-686) [v2.8.0] IOUtils.toByteArray(null) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-686:
---
Summary: [v2.8.0] IOUtils.toByteArray(null) Javadoc does not match code
(was: [v2.8.0] IOUtils.toByteArray(null) does not throw exception)
> [v2.8.0] IOUtils.toByteArray(null) Javadoc does not match code
> --
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Reporter: Alan Moffat
>Priority: Critical
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-686) [v2.8.0] IOUtils.toByteArray(null) does not throw exception
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Moffat updated IO-686:
---
Description:
According to the code in the v2.8.0 release, passing null to the method should
throw an exception, however it is producing an empty byte array instead.
{code:java}
/**
* Gets the contents of an InputStream as a byte[].
*
* This method buffers the input internally, so there is no need to use a
* BufferedInputStream.
*
*
* @param input the InputStream to read from
* @return the requested byte array
* @throws NullPointerException if the input is null
* @throws IOException if an I/O error occurs
*/
public static byte[] toByteArray(final InputStream input) throws IOException {
try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
copy(input, output);
return output.toByteArray();
}
} {code}
This can be recreated by the following:
{code:java}
@Test
public void shouldThrowNullPointerException() {
assertThrows(NullPointerException.class, () ->
IOUtils.toByteArray((InputStream) null))
} {code}
On v2.7 the test passes, on v2.8.0 it fails.
was:
According to the code in the v2.8.0 release, passing null to the method should
throw an exception, however it is producing an empty byte array instead.
{code:java}
/**
* Gets the contents of an InputStream as a byte[].
*
* This method buffers the input internally, so there is no need to use a
* BufferedInputStream.
*
*
* @param input the InputStream to read from
* @return the requested byte array
* @throws NullPointerException if the input is null
* @throws IOException if an I/O error occurs
*/
public static byte[] toByteArray(final InputStream input) throws IOException {
try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
copy(input, output);
return output.toByteArray();
}
} {code}
This can be recreated by the following:
{code:java}
@Test
public void shouldThrowNullPointerException() {
assertThrows(NullPointerException.class, () ->
IOUtils.toByteArray((InputStream) null))
} {code}
> [v2.8.0] IOUtils.toByteArray(null) does not throw exception
> ---
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Reporter: Alan Moffat
>Priority: Critical
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-686) [v2.8.0] IOUtils.toByteArray(null) does not throw exception
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Moffat updated IO-686:
---
Description:
According to the code in the v2.8.0 release, passing null to the method should
throw an exception, however it is producing an empty byte array instead.
{code:java}
/**
* Gets the contents of an InputStream as a byte[].
*
* This method buffers the input internally, so there is no need to use a
* BufferedInputStream.
*
*
* @param input the InputStream to read from
* @return the requested byte array
* @throws NullPointerException if the input is null
* @throws IOException if an I/O error occurs
*/
public static byte[] toByteArray(final InputStream input) throws IOException {
try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
copy(input, output);
return output.toByteArray();
}
} {code}
This can be recreated by the following:
{code:java}
@Test
public void shouldThrowNullPointerException() {
assertThrows(NullPointerException.class, () ->
IOUtils.toByteArray((InputStream) null))
} {code}
was:
According to the code in the v2.8.0 release, passing null to the method should
throw an exception, however it is producing an empty byte array instead.
{code:java}
/**
* Gets the contents of an InputStream as a byte[].
*
* This method buffers the input internally, so there is no need to use a
* BufferedInputStream.
*
*
* @param input the InputStream to read from
* @return the requested byte array
* @throws NullPointerException if the input is null
* @throws IOException if an I/O error occurs
*/
public static byte[] toByteArray(final InputStream input) throws IOException {
try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
copy(input, output);
return output.toByteArray();
}
} {code}
This can be recreated by the following:
{code:java}
@Test
public void shouldThrowNullPointerException() {
assertThrows(NullPointerException.class, () -> IOUtils.toByteArray(null))
} {code}
> [v2.8.0] IOUtils.toByteArray(null) does not throw exception
> ---
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Reporter: Alan Moffat
>Priority: Critical
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-686) [v2.8.0] IOUtils.toByteArray(null) does not throw exception
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Moffat updated IO-686:
---
Description:
According to the code in the v2.8.0 release, passing null to the method should
throw an exception, however it is producing an empty byte array instead.
{code:java}
/**
* Gets the contents of an InputStream as a byte[].
*
* This method buffers the input internally, so there is no need to use a
* BufferedInputStream.
*
*
* @param input the InputStream to read from
* @return the requested byte array
* @throws NullPointerException if the input is null
* @throws IOException if an I/O error occurs
*/
public static byte[] toByteArray(final InputStream input) throws IOException {
try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
copy(input, output);
return output.toByteArray();
}
} {code}
This can be recreated by the following:
{code:java}
@Test
public void shouldThrowNullPointerException() {
assertThrows(NullPointerException.class, () -> IOUtils.toByteArray(null))
} {code}
was:
According to the code in the v2.8.0 release, passing null to the method should
throw an exception, however it is producing an empty byte array instead.
{code:java}
/**
* Gets the contents of an InputStream as a byte[].
*
* This method buffers the input internally, so there is no need to use a
* BufferedInputStream.
*
*
* @param input the InputStream to read from
* @return the requested byte array
* @throws NullPointerException if the input is null
* @throws IOException if an I/O error occurs
*/
public static byte[] toByteArray(final InputStream input) throws IOException {
try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
copy(input, output);
return output.toByteArray();
}
} {code}
This can be recreated by the following:
{code:java}
@Test
public void shouldThrowNullPointerException() {
assertThrows(NullPointerException.class, () -> {
InputStream inputStream =
clazz.getResourceAsStream("non-existant-file.txt");
return IOUtils.toByteArray(inputStream);
}
} {code}
> [v2.8.0] IOUtils.toByteArray(null) does not throw exception
> ---
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Reporter: Alan Moffat
>Priority: Critical
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () -> IOUtils.toByteArray(null))
> } {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IO-686) [v2.8.0] IOUtils.toByteArray(null) does not throw exception
Alan Moffat created IO-686:
--
Summary: [v2.8.0] IOUtils.toByteArray(null) does not throw
exception
Key: IO-686
URL: https://issues.apache.org/jira/browse/IO-686
Project: Commons IO
Issue Type: Bug
Components: Utilities
Reporter: Alan Moffat
According to the code in the v2.8.0 release, passing null to the method should
throw an exception, however it is producing an empty byte array instead.
{code:java}
/**
* Gets the contents of an InputStream as a byte[].
*
* This method buffers the input internally, so there is no need to use a
* BufferedInputStream.
*
*
* @param input the InputStream to read from
* @return the requested byte array
* @throws NullPointerException if the input is null
* @throws IOException if an I/O error occurs
*/
public static byte[] toByteArray(final InputStream input) throws IOException {
try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
copy(input, output);
return output.toByteArray();
}
} {code}
This can be recreated by the following:
{code:java}
@Test
public void shouldThrowNullPointerException() {
assertThrows(NullPointerException.class, () -> {
InputStream inputStream =
clazz.getResourceAsStream("non-existant-file.txt");
return IOUtils.toByteArray(inputStream);
}
} {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-vfs] garydgregory merged pull request #125: Bump maven-pmd-plugin from 3.12.0 to 3.13.0
garydgregory merged pull request #125: URL: https://github.com/apache/commons-vfs/pull/125 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (FILEUPLOAD-265) .MultipartStream$MalformedStreamException: Stream ended unexpectedly
[ https://issues.apache.org/jira/browse/FILEUPLOAD-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193494#comment-17193494 ] Ralf Hauser commented on FILEUPLOAD-265: happens for us (intermittently) after the upgrade from tomcat8 to tomcat9 Others also have it [https://stackoverflow.com/questions/50244624/stream-ended-unexpectedly] do we newly have to set maxPostSize or maxSavePostSize in tomcat's global web.xml ? > .MultipartStream$MalformedStreamException: Stream ended unexpectedly > > > Key: FILEUPLOAD-265 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-265 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3.1 > Environment: httpclient >Reporter: zhumingu >Priority: Major > Labels: Stream, ended, unexpectedly > > When uploading files using the browser,it does not happen.But when submission > using tools with 'multipart/form-data',for example httpclient,advanced rest > client and so on, > Only submit a text field, file field is empty, it will report the following > exception: > org.apache.commons.fileupload.MultipartStream$MalformedStreamException: > Stream ended unexpectedly > at > org.apache.commons.fileupload.MultipartStream.readHeaders(MultipartStream.java:540) > at > org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:1038) > at > org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.(FileUploadBase.java:1003) > at > org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:310) > at > org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:334) > at > org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:115) > > A simple analysis that, when using the browser, file is not selected, the > default browser will join the empty data file-part. > But the use of tools such as httpclient, when the file is empty, it do not > contain the documents data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
