[jira] [Work logged] (COLLECTIONS-779) Migrate assert to Assertions
[
https://issues.apache.org/jira/browse/COLLECTIONS-779?focusedWorklogId=536960&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536960
]
ASF GitHub Bot logged work on COLLECTIONS-779:
--
Author: ASF GitHub Bot
Created on: 17/Jan/21 07:13
Start Date: 17/Jan/21 07:13
Worklog Time Spent: 10m
Work Description: arturobernalg commented on a change in pull request
#209:
URL:
https://github.com/apache/commons-collections/pull/209#discussion_r559089202
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionBuilderTest.java
##
@@ -86,14 +89,14 @@ public void
createPredicatedCollectionWithNotNullPredicate() {
}
private void checkPredicatedCollection1(final Collection
collection) {
-Assert.assertEquals(1, collection.size());
+assertEquals(1, collection.size());
collection.add("test2");
-Assert.assertEquals(2, collection.size());
+assertEquals(2, collection.size());
try {
collection.add(null);
-Assert.fail("Expecting IllegalArgumentException for failing
predicate!");
+fail("Expecting IllegalArgumentException for failing predicate!");
Review comment:
Done
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionBuilderTest.java
##
@@ -122,17 +125,17 @@ public void createPredicatedCollectionWithPredicate() {
}
private void checkPredicatedCollection2(final Collection
collection) {
-Assert.assertEquals(2, collection.size());
+assertEquals(2, collection.size());
try {
collection.add(4);
-Assert.fail("Expecting IllegalArgumentException for failing
predicate!");
+fail("Expecting IllegalArgumentException for failing predicate!");
Review comment:
Done
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
Issue Time Tracking
---
Worklog Id: (was: 536960)
Time Spent: 1.5h (was: 1h 20m)
> Migrate assert to Assertions
> -
>
> Key: COLLECTIONS-779
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-779
> Project: Commons Collections
> Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] arturobernalg commented on a change in pull request #209: [COLLECTIONS-779] - Migrate assert to Assertions
arturobernalg commented on a change in pull request #209:
URL:
https://github.com/apache/commons-collections/pull/209#discussion_r559089202
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionBuilderTest.java
##
@@ -86,14 +89,14 @@ public void
createPredicatedCollectionWithNotNullPredicate() {
}
private void checkPredicatedCollection1(final Collection
collection) {
-Assert.assertEquals(1, collection.size());
+assertEquals(1, collection.size());
collection.add("test2");
-Assert.assertEquals(2, collection.size());
+assertEquals(2, collection.size());
try {
collection.add(null);
-Assert.fail("Expecting IllegalArgumentException for failing
predicate!");
+fail("Expecting IllegalArgumentException for failing predicate!");
Review comment:
Done
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionBuilderTest.java
##
@@ -122,17 +125,17 @@ public void createPredicatedCollectionWithPredicate() {
}
private void checkPredicatedCollection2(final Collection
collection) {
-Assert.assertEquals(2, collection.size());
+assertEquals(2, collection.size());
try {
collection.add(4);
-Assert.fail("Expecting IllegalArgumentException for failing
predicate!");
+fail("Expecting IllegalArgumentException for failing predicate!");
Review comment:
Done
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] [Work logged] (COLLECTIONS-779) Migrate assert to Assertions
[
https://issues.apache.org/jira/browse/COLLECTIONS-779?focusedWorklogId=536922&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536922
]
ASF GitHub Bot logged work on COLLECTIONS-779:
--
Author: ASF GitHub Bot
Created on: 17/Jan/21 01:15
Start Date: 17/Jan/21 01:15
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #209:
URL:
https://github.com/apache/commons-collections/pull/209#discussion_r559061101
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionBuilderTest.java
##
@@ -86,14 +89,14 @@ public void
createPredicatedCollectionWithNotNullPredicate() {
}
private void checkPredicatedCollection1(final Collection
collection) {
-Assert.assertEquals(1, collection.size());
+assertEquals(1, collection.size());
collection.add("test2");
-Assert.assertEquals(2, collection.size());
+assertEquals(2, collection.size());
try {
collection.add(null);
-Assert.fail("Expecting IllegalArgumentException for failing
predicate!");
+fail("Expecting IllegalArgumentException for failing predicate!");
Review comment:
Use assertThrows()
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionBuilderTest.java
##
@@ -122,17 +125,17 @@ public void createPredicatedCollectionWithPredicate() {
}
private void checkPredicatedCollection2(final Collection
collection) {
-Assert.assertEquals(2, collection.size());
+assertEquals(2, collection.size());
try {
collection.add(4);
-Assert.fail("Expecting IllegalArgumentException for failing
predicate!");
+fail("Expecting IllegalArgumentException for failing predicate!");
Review comment:
Use assertThrows()
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
Issue Time Tracking
---
Worklog Id: (was: 536922)
Time Spent: 1h 20m (was: 1h 10m)
> Migrate assert to Assertions
> -
>
> Key: COLLECTIONS-779
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-779
> Project: Commons Collections
> Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] garydgregory commented on a change in pull request #209: [COLLECTIONS-779] - Migrate assert to Assertions
garydgregory commented on a change in pull request #209:
URL:
https://github.com/apache/commons-collections/pull/209#discussion_r559061101
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionBuilderTest.java
##
@@ -86,14 +89,14 @@ public void
createPredicatedCollectionWithNotNullPredicate() {
}
private void checkPredicatedCollection1(final Collection
collection) {
-Assert.assertEquals(1, collection.size());
+assertEquals(1, collection.size());
collection.add("test2");
-Assert.assertEquals(2, collection.size());
+assertEquals(2, collection.size());
try {
collection.add(null);
-Assert.fail("Expecting IllegalArgumentException for failing
predicate!");
+fail("Expecting IllegalArgumentException for failing predicate!");
Review comment:
Use assertThrows()
##
File path:
src/test/java/org/apache/commons/collections4/collection/PredicatedCollectionBuilderTest.java
##
@@ -122,17 +125,17 @@ public void createPredicatedCollectionWithPredicate() {
}
private void checkPredicatedCollection2(final Collection
collection) {
-Assert.assertEquals(2, collection.size());
+assertEquals(2, collection.size());
try {
collection.add(4);
-Assert.fail("Expecting IllegalArgumentException for failing
predicate!");
+fail("Expecting IllegalArgumentException for failing predicate!");
Review comment:
Use assertThrows()
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-693) FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently
[ https://issues.apache.org/jira/browse/IO-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1720#comment-1720 ] Gary D. Gregory commented on IO-693: [~xpyrus] Can this ticket be closed? > FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently > -- > > Key: IO-693 > URL: https://issues.apache.org/jira/browse/IO-693 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.8.0 >Reporter: Robert Seidel >Priority: Major > > # With the newly added PathUtils, the behavior of FileUtils.deleteDirectory > has changed. Now nio is used instead of the old File.delete. The problem is, > nio does not delete files with read only attribute and failes instead. > # The interface of FileUtils was not extended to provide the possibility to > use a DeleteOption, so I guess, if someone wants to remove "all" files, then > PathUtils should be used. But here comes the next problem, > FileUtils.deleteDirectory checks for the existence (in opposite to its > javadoc), where PathUtils.deleteDirectory does not. Thats very inconsistent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-695) Exception while there should be none in copyFile
[
https://issues.apache.org/jira/browse/IO-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266659#comment-17266659
]
Gary D. Gregory commented on IO-695:
[~morvael]
Please try again with git master as the internals are now different.
> Exception while there should be none in copyFile
>
>
> Key: IO-695
> URL: https://issues.apache.org/jira/browse/IO-695
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Dominik Derwiński
>Priority: Minor
>
> {{public static void copyFile(final File srcFile, final File destFile, final
> boolean preserveFileDate)}} java doc says: "If the modification operation
> fails, no indication is provided", yet the method raises an {{IOException}}
> "Failed setLastModified on ...".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IO-696) IOUtils.toByteArray throws inconsistent exceptions
[
https://issues.apache.org/jira/browse/IO-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266657#comment-17266657
]
Gary D. Gregory commented on IO-696:
Hi [~abchaubey]
Please check the current git master. The PR might be obsolete by recent
changes. Please confirm.
TY!
> IOUtils.toByteArray throws inconsistent exceptions
> --
>
> Key: IO-696
> URL: https://issues.apache.org/jira/browse/IO-696
> Project: Commons IO
> Issue Type: Bug
>Reporter: ackelcn
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The code of this method is as follows:
> {code:java}
> public static byte[] toByteArray(final InputStream input, final int size)
> throws IOException {
> if (size < 0) {
> throw new IllegalArgumentException("Size must be equal or greater
> than zero: " + size);
> }if (size == 0) {
> return new byte[0];
> }final byte[] data = new byte[size];
> int offset = 0;
> int read;while (offset < size && (read = input.read(data,
> offset, size - offset)) != EOF) {
> offset += read;
> }
> if (offset != size) {
> throw new IOException("Unexpected read size. current: " + offset
> + ", expected: " + size);
> }return data;
> }
> {code}
> When size is below zero, it throws IllegalArgumentException, but when size is
> not equal to offset, it throws IOException. It is somewhat confusing. It
> shall throw IOException in both cases, in that both cases check legal sizes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-702.
Fix Version/s: 2.9.0
Resolution: Fixed
[~xf01213]
Thank you for your PR. Merged in git master. Please verify and close this
ticket.
TY!
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Fix For: 2.9.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?focusedWorklogId=536878&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536878
]
ASF GitHub Bot logged work on IO-702:
-
Author: ASF GitHub Bot
Created on: 16/Jan/21 20:55
Start Date: 16/Jan/21 20:55
Worklog Time Spent: 10m
Work Description: garydgregory merged pull request #187:
URL: https://github.com/apache/commons-io/pull/187
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
Issue Time Tracking
---
Worklog Id: (was: 536878)
Time Spent: 2.5h (was: 2h 20m)
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] garydgregory merged pull request #187: IO-702 FileUtils.forceDelete does not delete invalid links. Testcase …
garydgregory merged pull request #187: URL: https://github.com/apache/commons-io/pull/187 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] [Work logged] (COLLECTIONS-779) Migrate assert to Assertions
[ https://issues.apache.org/jira/browse/COLLECTIONS-779?focusedWorklogId=536877&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536877 ] ASF GitHub Bot logged work on COLLECTIONS-779: -- Author: ASF GitHub Bot Created on: 16/Jan/21 20:46 Start Date: 16/Jan/21 20:46 Worklog Time Spent: 10m Work Description: arturobernalg commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r559037897 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: HI @garydgregory I can imagine. My idea it's split the migration in several PR. In that way i can reduce the number of file to review and reduce the errors 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 Issue Time Tracking --- Worklog Id: (was: 536877) Time Spent: 1h 10m (was: 1h) > Migrate assert to Assertions > - > > Key: COLLECTIONS-779 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-779 > Project: Commons Collections > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COLLECTIONS-779) Migrate assert to Assertions
[ https://issues.apache.org/jira/browse/COLLECTIONS-779?focusedWorklogId=536876&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536876 ] ASF GitHub Bot logged work on COLLECTIONS-779: -- Author: ASF GitHub Bot Created on: 16/Jan/21 20:46 Start Date: 16/Jan/21 20:46 Worklog Time Spent: 10m Work Description: arturobernalg commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r559037897 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: I can imagine. My idea it's split the migration in several PR. In that way i can reduce the number of file to review and reduce the errors 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 Issue Time Tracking --- Worklog Id: (was: 536876) Time Spent: 1h (was: 50m) > Migrate assert to Assertions > - > > Key: COLLECTIONS-779 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-779 > Project: Commons Collections > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] arturobernalg commented on a change in pull request #209: [COLLECTIONS-779] - Migrate assert to Assertions
arturobernalg commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r559037897 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: HI @garydgregory I can imagine. My idea it's split the migration in several PR. In that way i can reduce the number of file to review and reduce the errors 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-collections] arturobernalg commented on a change in pull request #209: [COLLECTIONS-779] - Migrate assert to Assertions
arturobernalg commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r559037897 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: I can imagine. My idea it's split the migration in several PR. In that way i can reduce the number of file to review and reduce the errors 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] [Work logged] (COLLECTIONS-779) Migrate assert to Assertions
[ https://issues.apache.org/jira/browse/COLLECTIONS-779?focusedWorklogId=536856&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536856 ] ASF GitHub Bot logged work on COLLECTIONS-779: -- Author: ASF GitHub Bot Created on: 16/Jan/21 19:50 Start Date: 16/Jan/21 19:50 Worklog Time Spent: 10m Work Description: garydgregory commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r559024180 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: I don't have specific advice, that is some older code initially based on JUnit 3. 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 Issue Time Tracking --- Worklog Id: (was: 536856) Time Spent: 50m (was: 40m) > Migrate assert to Assertions > - > > Key: COLLECTIONS-779 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-779 > Project: Commons Collections > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] garydgregory commented on a change in pull request #209: [COLLECTIONS-779] - Migrate assert to Assertions
garydgregory commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r559024180 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: I don't have specific advice, that is some older code initially based on JUnit 3. 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] [Work logged] (COLLECTIONS-779) Migrate assert to Assertions
[ https://issues.apache.org/jira/browse/COLLECTIONS-779?focusedWorklogId=536854&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536854 ] ASF GitHub Bot logged work on COLLECTIONS-779: -- Author: ASF GitHub Bot Created on: 16/Jan/21 19:36 Start Date: 16/Jan/21 19:36 Worklog Time Spent: 10m Work Description: arturobernalg commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r559018794 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: HI @garydgregory Nop. I don't. I working on change/migrate the rest of the class. Trying to find out how migrate the BulkTest that extends TestCase hehehe. Any advice is more than welcome 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 Issue Time Tracking --- Worklog Id: (was: 536854) Time Spent: 40m (was: 0.5h) > Migrate assert to Assertions > - > > Key: COLLECTIONS-779 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-779 > Project: Commons Collections > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] arturobernalg commented on a change in pull request #209: [COLLECTIONS-779] - Migrate assert to Assertions
arturobernalg commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r559018794 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: HI @garydgregory Nop. I don't. I working on change/migrate the rest of the class. Trying to find out how migrate the BulkTest that extends TestCase hehehe. Any advice is more than welcome 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] [Work logged] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?focusedWorklogId=536850&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536850
]
ASF GitHub Bot logged work on IO-702:
-
Author: ASF GitHub Bot
Created on: 16/Jan/21 19:05
Start Date: 16/Jan/21 19:05
Worklog Time Spent: 10m
Work Description: boris-unckel commented on pull request #187:
URL: https://github.com/apache/commons-io/pull/187#issuecomment-761616980
@garydgregory
Fixed the DeletingPathVisitor.visitFile with an additional check for
symlinks. Please review again.
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
Issue Time Tracking
---
Worklog Id: (was: 536850)
Time Spent: 2h 20m (was: 2h 10m)
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] boris-unckel commented on pull request #187: IO-702 FileUtils.forceDelete does not delete invalid links. Testcase …
boris-unckel commented on pull request #187: URL: https://github.com/apache/commons-io/pull/187#issuecomment-761616980 @garydgregory Fixed the DeletingPathVisitor.visitFile with an additional check for symlinks. Please review again. 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] [Work logged] (COLLECTIONS-779) Migrate assert to Assertions
[ https://issues.apache.org/jira/browse/COLLECTIONS-779?focusedWorklogId=536848&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536848 ] ASF GitHub Bot logged work on COLLECTIONS-779: -- Author: ASF GitHub Bot Created on: 16/Jan/21 19:02 Start Date: 16/Jan/21 19:02 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #209: URL: https://github.com/apache/commons-collections/pull/209#issuecomment-761616672 [](https://coveralls.io/builds/36376167) Coverage decreased (-0.05%) to 90.136% when pulling **7f5215ca2e21f07d64d7f83f3c3bca574457ff7a on arturobernalg:feature/COLLECTIONS-779** into **9691a48354d1a97d470b9184bb98da088c97e9d9 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 Issue Time Tracking --- Worklog Id: (was: 536848) Time Spent: 0.5h (was: 20m) > Migrate assert to Assertions > - > > Key: COLLECTIONS-779 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-779 > Project: Commons Collections > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] coveralls commented on pull request #209: [COLLECTIONS-779] - Migrate assert to Assertions
coveralls commented on pull request #209: URL: https://github.com/apache/commons-collections/pull/209#issuecomment-761616672 [](https://coveralls.io/builds/36376167) Coverage decreased (-0.05%) to 90.136% when pulling **7f5215ca2e21f07d64d7f83f3c3bca574457ff7a on arturobernalg:feature/COLLECTIONS-779** into **9691a48354d1a97d470b9184bb98da088c97e9d9 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-collections] garydgregory merged pull request #208: Minor Improvements
garydgregory merged pull request #208: URL: https://github.com/apache/commons-collections/pull/208 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] [Work logged] (COLLECTIONS-779) Migrate assert to Assertions
[ https://issues.apache.org/jira/browse/COLLECTIONS-779?focusedWorklogId=536835&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536835 ] ASF GitHub Bot logged work on COLLECTIONS-779: -- Author: ASF GitHub Bot Created on: 16/Jan/21 17:20 Start Date: 16/Jan/21 17:20 Worklog Time Spent: 10m Work Description: garydgregory commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r558970391 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: @arturobernalg Did you forget to flip the arguments on the `assert*` API calls in this file and subsequent files? 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 Issue Time Tracking --- Worklog Id: (was: 536835) Time Spent: 20m (was: 10m) > Migrate assert to Assertions > - > > Key: COLLECTIONS-779 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-779 > Project: Commons Collections > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] garydgregory commented on a change in pull request #209: [COLLECTIONS-779] - Migrate assert to Assertions
garydgregory commented on a change in pull request #209: URL: https://github.com/apache/commons-collections/pull/209#discussion_r558970391 ## File path: src/test/java/org/apache/commons/collections4/iterators/LoopingListIteratorTest.java ## @@ -21,8 +21,8 @@ import java.util.List; import java.util.NoSuchElementException; -import org.junit.Test; -import static org.junit.Assert.*; +import org.junit.jupiter.api.Test; +import static org.junit.jupiter.api.Assertions.*; Review comment: @arturobernalg Did you forget to flip the arguments on the `assert*` API calls in this file and subsequent files? 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-collections] garydgregory merged pull request #204: Bump checkstyle from 8.38 to 8.39
garydgregory merged pull request #204: URL: https://github.com/apache/commons-collections/pull/204 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] [Deleted] (COMMONSSITE-142) Indo Play Poker
[ https://issues.apache.org/jira/browse/COMMONSSITE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory deleted COMMONSSITE-142: > Indo Play Poker > --- > > Key: COMMONSSITE-142 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-142 > Project: Apache Commons All > Issue Type: Bug >Reporter: Indo Poker APK >Priority: Major > > http://indo-play.com/";>Indo-Play Poker IDN > http://indo-play.com/";>IDN Play Versi 1.1.12.0 Android > http://indo-play.com/";>Indo Poker APK > http://indo-play.com/daftar-indo-play-idn-poker/";>Daftar Indo Play > IDN Poker > http://indo-play.com/download-indo-play-idn-poker/";>Download Indo > Play IDN Poker > http://indo-play.com/login-indo-play-idnpoker/";>Login Indo Play > IdnPoker > http://indo-play.com/deposit-indo-idn-play-poker/";>Deposit Indo IDN > Play Poker > http://indo-play.com/link-idn-poker/";>Link IDN Poker -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-703) FileUtils.directoryContains shall throw NullPointerException for null inputs
[
https://issues.apache.org/jira/browse/IO-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266592#comment-17266592
]
Gary D. Gregory commented on IO-703:
Please see git master.
> FileUtils.directoryContains shall throw NullPointerException for null inputs
>
>
> Key: IO-703
> URL: https://issues.apache.org/jira/browse/IO-703
> Project: Commons IO
> Issue Type: Bug
>Reporter: Hao Zhong
>Priority: Major
>
> The code of this method is as follows:
> {code:java}
> public static boolean directoryContains(final File directory, final File
> child) throws IOException {// Fail fast against NullPointerException
> if (directory == null) {
> throw new IllegalArgumentException("Directory must not be null");
> }if (!directory.isDirectory()) {
> throw new IllegalArgumentException("Not a directory: " +
> directory);
> }
>...
> }{code}
> When directory is null, it throws IllegalArgumentException, but all the other
> methods of this class throw NullPointerException:
>
> {code:java}
>public static void copyToDirectory(final File src, final File destDir)
> throws IOException {
> if (src == null) {
> throw new NullPointerException("Source must not be null");
> }
>
> }{code}
>
> {code:java}
> private static void checkFileRequirements(final File src, final File dest)
> throws FileNotFoundException {
> if (src == null) {
> throw new NullPointerException("Source must not be null");
> }
> if (dest == null) {
> throw new NullPointerException("Destination must not be null");
> }
> if (!src.exists()) {
> throw new FileNotFoundException("Source '" + src + "' does not
> exist");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-geometry] darkma773r merged pull request #129: Minor Improvement:
darkma773r merged pull request #129: URL: https://github.com/apache/commons-geometry/pull/129 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] [Work logged] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?focusedWorklogId=536772&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536772
]
ASF GitHub Bot logged work on IO-702:
-
Author: ASF GitHub Bot
Created on: 16/Jan/21 10:33
Start Date: 16/Jan/21 10:33
Worklog Time Spent: 10m
Work Description: boris-unckel edited a comment on pull request #187:
URL: https://github.com/apache/commons-io/pull/187#issuecomment-761536421
@garydgregory
Now it fails again in deleteDirectory (which is not the cause)
`Error:
org.apache.commons.io.FileUtilsDeleteDirectoryLinuxTestCase.testDeleteInvalidLinks
Time elapsed: 0.003 s <<< ERROR!
java.nio.file.DirectoryNotEmptyException:
/tmp/junit16834268871756684963/realParentDirC
at
java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:247)
at
java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
at java.base/java.nio.file.Files.delete(Files.java:1141)
at org.apache.commons.io.FileUtils.delete(FileUtils.java:1170)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189)
at
org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)`
IMO This stacktrace is misleading because originally forceDelete fails to
delete the broken link. It's in the DeletingPathVisitor.visitFile:
For the broken link "linkToB" Files.exists(file, linkOptions) returns false.
For regular links and regular files it returns true.
FileUtils.forceDelete does
`deleteCounters = PathUtils.delete(file.toPath(),
PathUtils.EMPTY_LINK_OPTION_ARRAY,
StandardDeleteOption.OVERRIDE_READ_ONLY);`
but `Files.exists(file, linkOptions)` needs
`PathUtils.NOFOLLOW_LINK_OPTION_ARRAY` to recognize the broken link exists.
A change in forceDelete will not help - this causes (a) destinations of
links deleted and (b) a NoSuchFileException later, because a broken link does
not point to a file.
What do you suggest?
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
Issue Time Tracking
---
Worklog Id: (was: 536772)
Time Spent: 2h 10m (was: 2h)
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] boris-unckel edited a comment on pull request #187: IO-702 FileUtils.forceDelete does not delete invalid links. Testcase …
boris-unckel edited a comment on pull request #187: URL: https://github.com/apache/commons-io/pull/187#issuecomment-761536421 @garydgregory Now it fails again in deleteDirectory (which is not the cause) `Error: org.apache.commons.io.FileUtilsDeleteDirectoryLinuxTestCase.testDeleteInvalidLinks Time elapsed: 0.003 s <<< ERROR! java.nio.file.DirectoryNotEmptyException: /tmp/junit16834268871756684963/realParentDirC at java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:247) at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105) at java.base/java.nio.file.Files.delete(Files.java:1141) at org.apache.commons.io.FileUtils.delete(FileUtils.java:1170) at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189) at org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)` IMO This stacktrace is misleading because originally forceDelete fails to delete the broken link. It's in the DeletingPathVisitor.visitFile: For the broken link "linkToB" Files.exists(file, linkOptions) returns false. For regular links and regular files it returns true. FileUtils.forceDelete does `deleteCounters = PathUtils.delete(file.toPath(), PathUtils.EMPTY_LINK_OPTION_ARRAY, StandardDeleteOption.OVERRIDE_READ_ONLY);` but `Files.exists(file, linkOptions)` needs `PathUtils.NOFOLLOW_LINK_OPTION_ARRAY` to recognize the broken link exists. A change in forceDelete will not help - this causes (a) destinations of links deleted and (b) a NoSuchFileException later, because a broken link does not point to a file. What do you suggest? 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] [Work logged] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?focusedWorklogId=536766&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536766
]
ASF GitHub Bot logged work on IO-702:
-
Author: ASF GitHub Bot
Created on: 16/Jan/21 10:12
Start Date: 16/Jan/21 10:12
Worklog Time Spent: 10m
Work Description: boris-unckel edited a comment on pull request #187:
URL: https://github.com/apache/commons-io/pull/187#issuecomment-761536421
@garydgregory
Now it fails again in deleteDirectory (which is not the cause)
`Error:
org.apache.commons.io.FileUtilsDeleteDirectoryLinuxTestCase.testDeleteInvalidLinks
Time elapsed: 0.003 s <<< ERROR!
java.nio.file.DirectoryNotEmptyException:
/tmp/junit16834268871756684963/realParentDirC
at
java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:247)
at
java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
at java.base/java.nio.file.Files.delete(Files.java:1141)
at org.apache.commons.io.FileUtils.delete(FileUtils.java:1170)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189)
at
org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)`
IMO This stacktrace is misleading because originally forceDelete fails to
delete the broken link. It's in the DeletingPathVisitor.visitFile:
For the broken link "linkToB" Files.exists(file, linkOptions) returns false.
For regular links and regular files it returns true.
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
Issue Time Tracking
---
Worklog Id: (was: 536766)
Time Spent: 2h (was: 1h 50m)
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 2h
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] boris-unckel edited a comment on pull request #187: IO-702 FileUtils.forceDelete does not delete invalid links. Testcase …
boris-unckel edited a comment on pull request #187: URL: https://github.com/apache/commons-io/pull/187#issuecomment-761536421 @garydgregory Now it fails again in deleteDirectory (which is not the cause) `Error: org.apache.commons.io.FileUtilsDeleteDirectoryLinuxTestCase.testDeleteInvalidLinks Time elapsed: 0.003 s <<< ERROR! java.nio.file.DirectoryNotEmptyException: /tmp/junit16834268871756684963/realParentDirC at java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:247) at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105) at java.base/java.nio.file.Files.delete(Files.java:1141) at org.apache.commons.io.FileUtils.delete(FileUtils.java:1170) at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189) at org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)` IMO This stacktrace is misleading because originally forceDelete fails to delete the broken link. It's in the DeletingPathVisitor.visitFile: For the broken link "linkToB" Files.exists(file, linkOptions) returns false. For regular links and regular files it returns true. 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] [Work logged] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?focusedWorklogId=536762&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536762
]
ASF GitHub Bot logged work on IO-702:
-
Author: ASF GitHub Bot
Created on: 16/Jan/21 09:52
Start Date: 16/Jan/21 09:52
Worklog Time Spent: 10m
Work Description: boris-unckel commented on pull request #187:
URL: https://github.com/apache/commons-io/pull/187#issuecomment-761536421
@garydgregory
Now it fails again in deleteDirectory (which is not the cause)
`Error:
org.apache.commons.io.FileUtilsDeleteDirectoryLinuxTestCase.testDeleteInvalidLinks
Time elapsed: 0.003 s <<< ERROR!
java.nio.file.DirectoryNotEmptyException:
/tmp/junit16834268871756684963/realParentDirC
at
java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:247)
at
java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
at java.base/java.nio.file.Files.delete(Files.java:1141)
at org.apache.commons.io.FileUtils.delete(FileUtils.java:1170)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189)
at
org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)`
IMO This stacktrace is misleading because originally forceDelete fails to
delete the broken link. Maybe it's the Visitor in the nio TreeWalker.
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
Issue Time Tracking
---
Worklog Id: (was: 536762)
Time Spent: 1h 50m (was: 1h 40m)
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] boris-unckel commented on pull request #187: IO-702 FileUtils.forceDelete does not delete invalid links. Testcase …
boris-unckel commented on pull request #187: URL: https://github.com/apache/commons-io/pull/187#issuecomment-761536421 @garydgregory Now it fails again in deleteDirectory (which is not the cause) `Error: org.apache.commons.io.FileUtilsDeleteDirectoryLinuxTestCase.testDeleteInvalidLinks Time elapsed: 0.003 s <<< ERROR! java.nio.file.DirectoryNotEmptyException: /tmp/junit16834268871756684963/realParentDirC at java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:247) at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105) at java.base/java.nio.file.Files.delete(Files.java:1141) at org.apache.commons.io.FileUtils.delete(FileUtils.java:1170) at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189) at org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)` IMO This stacktrace is misleading because originally forceDelete fails to delete the broken link. Maybe it's the Visitor in the nio TreeWalker. 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] [Comment Edited] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
[
https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266536#comment-17266536
]
Peter Lee edited comment on COMPRESS-562 at 1/16/21, 9:47 AM:
--
Disclaimer : not familiar with zpk
I checked the apk file(test-services-1.1.0.apk) and found something strange :
There are 237 bytes of zero before the actual apk signing block.
!apk.PNG!
These redundant bytes of zero broke the read of apk signing block - that's why
we are throwing the unexpected record signature exception. And I can
successfully read this apk file with these bytes removed.
Accoarding to the [apk signing block
specification|https://source.android.com/security/apksigning/v2], these bytes
are not mentioned. Please feel free to tell me if they are reasonable.
In short words, I believe the apk file is corrupted and could not be
successfully read using ZipArchiveInputStream(but can be read with ZipFile).
BTW : Why java standard zip(ZipInputStream) can successfully read this apk?
I check the code of ZipInputStream and found they didn't check if a Central
Directory File or APK signing block is met. They simply return null if the
signature is not the one of Local File Header. That's why they didn't report
any exceptions.
See also : [ZipInputStream in
OpenJDK|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L284]
was (Author: peterlee):
Disclaimer : not familiar with zpk
I checked the apk file(test-services-1.1.0.apk) and found something strange :
There are 237 bytes of zero before the actual apk signing block.
!apk.PNG!
These redundant bytes of zero broke the read of apk signing block - that's why
we are throwing the unexpected record signature exception. And I can
successfully read this apk file with these bytes removed.
Accoarding to the [apk signing block
specification|[https://source.android.com/security/apksigning/v2]], these
bytes are not mentioned. Please feel free to tell me if they are reasonable.
In short words, I believe the apk file is corrupted and could not be
successfully read using ZipArchiveInputStream(but can be read with ZipFile).
BTW : Why java standard zip(ZipInputStream) can successfully read this apk?
I check the code of ZipInputStream and found they didn't check if a Central
Directory File or APK signing block is met. They simply return null if the
signature is not the one of Local File Header. That's why they didn't report
any exceptions.
See also : [ZipInputStream in
OpenJDK|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L284]
> ZipArchiveInputStream fails with unexpected record signature while
> ZipInputStream from java.util.zip succeeds
> -
>
> Key: COMPRESS-562
> URL: https://issues.apache.org/jira/browse/COMPRESS-562
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
> Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc
> 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X)
> on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>Reporter: Oleksii Khomchenko
>Priority: Major
> Attachments: apk.PNG, test-services-1.1.0.apk
>
>
> Thank you a lot for the library.
>
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record
> signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from
> [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0]
> via commons-compress:1.20 while java.util.zip reads it without the exception.
>
> {code:java}
> public class UnzipTestServicesSample {
> public static void main(String[] args) throws Exception {
> Path p = Paths.get("test-services-1.1.0.apk");
> System.out.println("\n=== java std zip ===\n");
> try (InputStream is = Files.newInputStream(p); ZipInputStream zis =
> new ZipInputStream(is)) {
> ZipEntry entry;
> while ((entry = zis.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> System.out.println("\n=== apache compress zip ===\n");
> try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais
> = new ZipArchiveInputStream(is)) {
> ArchiveEntry entry;
> while ((entry = ais.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> }
> }{code}
>
> zip -T says that archive is fine:
>
> {code:java}
> $ zip -T
[jira] [Comment Edited] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
[
https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266536#comment-17266536
]
Peter Lee edited comment on COMPRESS-562 at 1/16/21, 9:46 AM:
--
Disclaimer : not familiar with zpk
I checked the apk file(test-services-1.1.0.apk) and found something strange :
There are 237 bytes of zero before the actual apk signing block.
!apk.PNG!
These redundant bytes of zero broke the read of apk signing block - that's why
we are throwing the unexpected record signature exception. And I can
successfully read this apk file with these bytes removed.
Accoarding to the [apk signing block
specification|[https://source.android.com/security/apksigning/v2]], these
bytes are not mentioned. Please feel free to tell me if they are reasonable.
In short words, I believe the apk file is corrupted and could not be
successfully read using ZipArchiveInputStream(but can be read with ZipFile).
BTW : Why java standard zip(ZipInputStream) can successfully read this apk?
I check the code of ZipInputStream and found they didn't check if a Central
Directory File or APK signing block is met. They simply return null if the
signature is not the one of Local File Header. That's why they didn't report
any exceptions.
See also : [ZipInputStream in
OpenJDK|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L284]
was (Author: peterlee):
Disclaimer : not familiar with zpk
I checked the apk file(test-services-1.1.0.apk) and found something strange :
There are 237 bytes of zero before the actual apk signing block.
!apk.PNG!
These redundant bytes of zero broke the read of apk signing block - that's why
we are throwing the unexpected record signature exception. And I can
successfully read this apk file with these bytes removed.
Accoarding to the [apk signing block
specification|[https://source.android.com/security/apksigning/v2],] these bytes
are not mentioned. Please feel free to tell me if they are reasonable.
In short words, I believe the apk file is corrupted and could not be
successfully read using ZipArchiveInputStream(but can be read with ZipFile).
BTW : Why java standard zip(ZipInputStream) can successfully read this apk?
I check the code of ZipInputStream and found they didn't check if a Central
Directory File or APK signing block is met. They simply return null if the
signature is not the one of Local File Header. That's why they didn't report
any exceptions.
See also : [ZipInputStream in
OpenJDK|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L284]
> ZipArchiveInputStream fails with unexpected record signature while
> ZipInputStream from java.util.zip succeeds
> -
>
> Key: COMPRESS-562
> URL: https://issues.apache.org/jira/browse/COMPRESS-562
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
> Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc
> 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X)
> on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>Reporter: Oleksii Khomchenko
>Priority: Major
> Attachments: apk.PNG, test-services-1.1.0.apk
>
>
> Thank you a lot for the library.
>
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record
> signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from
> [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0]
> via commons-compress:1.20 while java.util.zip reads it without the exception.
>
> {code:java}
> public class UnzipTestServicesSample {
> public static void main(String[] args) throws Exception {
> Path p = Paths.get("test-services-1.1.0.apk");
> System.out.println("\n=== java std zip ===\n");
> try (InputStream is = Files.newInputStream(p); ZipInputStream zis =
> new ZipInputStream(is)) {
> ZipEntry entry;
> while ((entry = zis.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> System.out.println("\n=== apache compress zip ===\n");
> try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais
> = new ZipArchiveInputStream(is)) {
> ArchiveEntry entry;
> while ((entry = ais.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> }
> }{code}
>
> zip -T says that archive is fine:
>
> {code:java}
> $ zip -
[jira] [Comment Edited] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
[
https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266536#comment-17266536
]
Peter Lee edited comment on COMPRESS-562 at 1/16/21, 9:45 AM:
--
Disclaimer : not familiar with zpk
I checked the apk file(test-services-1.1.0.apk) and found something strange :
There are 237 bytes of zero before the actual apk signing block.
!apk.PNG!
These redundant bytes of zero broke the read of apk signing block - that's why
we are throwing the unexpected record signature exception. And I can
successfully read this apk file with these bytes removed.
Accoarding to the [apk signing block
specification|[https://source.android.com/security/apksigning/v2],] these bytes
are not mentioned. Please feel free to tell me if they are reasonable.
In short words, I believe the apk file is corrupted and could not be
successfully read using ZipArchiveInputStream(but can be read with ZipFile).
BTW : Why java standard zip(ZipInputStream) can successfully read this apk?
I check the code of ZipInputStream and found they didn't check if a Central
Directory File or APK signing block is met. They simply return null if the
signature is not the one of Local File Header. That's why they didn't report
any exceptions.
See also : [ZipInputStream in
OpenJDK|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L284]
was (Author: peterlee):
Disclaimer : not familiar with zpk
I checked the apk file(test-services-1.1.0.apk) and found something strange :
There are 237 bytes of zero before the actual apk signing block.
!apk.PNG!
These redundant bytes of zero broke the read of apk signing block - that's why
we are throwing the unexpected record signature exception. And I can
successfully read this apk file with these bytes removed.
Accoarding to the [apk signing block
specification|[https://source.android.com/security/apksigning/v2]
,|https://source.android.com/security/apksigning/v2],]these bytes are not
mentioned. Please feel free to tell me if they are reasonable.
In short words, I believe the apk file is corrupted and could not be
successfully read using ZipArchiveInputStream(but can be read with ZipFile).
BTW : Why java standard zip(ZipInputStream) can successfully read this apk?
I check the code of ZipInputStream and found they didn't check if a Central
Directory File or APK signing block is met. They simply return null if the
signature is not the one of Local File Header. That's why they didn't report
any exceptions.
See also : [ZipInputStream in
OpenJDK|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L284]
> ZipArchiveInputStream fails with unexpected record signature while
> ZipInputStream from java.util.zip succeeds
> -
>
> Key: COMPRESS-562
> URL: https://issues.apache.org/jira/browse/COMPRESS-562
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
> Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc
> 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X)
> on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>Reporter: Oleksii Khomchenko
>Priority: Major
> Attachments: apk.PNG, test-services-1.1.0.apk
>
>
> Thank you a lot for the library.
>
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record
> signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from
> [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0]
> via commons-compress:1.20 while java.util.zip reads it without the exception.
>
> {code:java}
> public class UnzipTestServicesSample {
> public static void main(String[] args) throws Exception {
> Path p = Paths.get("test-services-1.1.0.apk");
> System.out.println("\n=== java std zip ===\n");
> try (InputStream is = Files.newInputStream(p); ZipInputStream zis =
> new ZipInputStream(is)) {
> ZipEntry entry;
> while ((entry = zis.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> System.out.println("\n=== apache compress zip ===\n");
> try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais
> = new ZipArchiveInputStream(is)) {
> ArchiveEntry entry;
> while ((entry = ais.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> }
> }{code}
>
> zip -T sa
[jira] [Work logged] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?focusedWorklogId=536760&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536760
]
ASF GitHub Bot logged work on IO-702:
-
Author: ASF GitHub Bot
Created on: 16/Jan/21 09:44
Start Date: 16/Jan/21 09:44
Worklog Time Spent: 10m
Work Description: boris-unckel commented on a change in pull request #187:
URL: https://github.com/apache/commons-io/pull/187#discussion_r558832817
##
File path: src/main/java/org/apache/commons/io/FileUtils.java
##
@@ -309,6 +309,9 @@ public static void cleanDirectory(final File directory)
throws IOException {
if (!causeList.isEmpty()) {
throw new IOExceptionList(causeList);
}
+if (listFiles(directory, null).length > 0) {
Review comment:
obsolete - it's removed, see later comment
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
Issue Time Tracking
---
Worklog Id: (was: 536760)
Time Spent: 1h 40m (was: 1.5h)
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?focusedWorklogId=536759&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536759
]
ASF GitHub Bot logged work on IO-702:
-
Author: ASF GitHub Bot
Created on: 16/Jan/21 09:44
Start Date: 16/Jan/21 09:44
Worklog Time Spent: 10m
Work Description: boris-unckel commented on a change in pull request #187:
URL: https://github.com/apache/commons-io/pull/187#discussion_r558832787
##
File path: src/main/java/org/apache/commons/io/FileUtils.java
##
@@ -1342,6 +1345,9 @@ public static void forceDelete(final File file) throws
IOException {
// didn't find a file to delete.
throw new FileNotFoundException("File does not exist: " + file);
}
+if (file.exists()) {
Review comment:
removed
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
Issue Time Tracking
---
Worklog Id: (was: 536759)
Time Spent: 1.5h (was: 1h 20m)
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?focusedWorklogId=536758&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536758
]
ASF GitHub Bot logged work on IO-702:
-
Author: ASF GitHub Bot
Created on: 16/Jan/21 09:44
Start Date: 16/Jan/21 09:44
Worklog Time Spent: 10m
Work Description: boris-unckel commented on a change in pull request #187:
URL: https://github.com/apache/commons-io/pull/187#discussion_r558832779
##
File path: src/main/java/org/apache/commons/io/FileUtils.java
##
@@ -309,6 +309,9 @@ public static void cleanDirectory(final File directory)
throws IOException {
if (!causeList.isEmpty()) {
throw new IOExceptionList(causeList);
}
+if (listFiles(directory, null).length > 0) {
+throw new IOException("Directory " + directory + " is not empty,
cleaning attempt failed.");
Review comment:
removed
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
Issue Time Tracking
---
Worklog Id: (was: 536758)
Time Spent: 1h 20m (was: 1h 10m)
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] boris-unckel commented on a change in pull request #187: IO-702 FileUtils.forceDelete does not delete invalid links. Testcase …
boris-unckel commented on a change in pull request #187:
URL: https://github.com/apache/commons-io/pull/187#discussion_r558832817
##
File path: src/main/java/org/apache/commons/io/FileUtils.java
##
@@ -309,6 +309,9 @@ public static void cleanDirectory(final File directory)
throws IOException {
if (!causeList.isEmpty()) {
throw new IOExceptionList(causeList);
}
+if (listFiles(directory, null).length > 0) {
Review comment:
obsolete - it's removed, see later comment
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-io] boris-unckel commented on a change in pull request #187: IO-702 FileUtils.forceDelete does not delete invalid links. Testcase …
boris-unckel commented on a change in pull request #187:
URL: https://github.com/apache/commons-io/pull/187#discussion_r558832787
##
File path: src/main/java/org/apache/commons/io/FileUtils.java
##
@@ -1342,6 +1345,9 @@ public static void forceDelete(final File file) throws
IOException {
// didn't find a file to delete.
throw new FileNotFoundException("File does not exist: " + file);
}
+if (file.exists()) {
Review comment:
removed
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-io] boris-unckel commented on a change in pull request #187: IO-702 FileUtils.forceDelete does not delete invalid links. Testcase …
boris-unckel commented on a change in pull request #187:
URL: https://github.com/apache/commons-io/pull/187#discussion_r558832779
##
File path: src/main/java/org/apache/commons/io/FileUtils.java
##
@@ -309,6 +309,9 @@ public static void cleanDirectory(final File directory)
throws IOException {
if (!causeList.isEmpty()) {
throw new IOExceptionList(causeList);
}
+if (listFiles(directory, null).length > 0) {
+throw new IOException("Directory " + directory + " is not empty,
cleaning attempt failed.");
Review comment:
removed
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] [Work logged] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?focusedWorklogId=536757&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-536757
]
ASF GitHub Bot logged work on IO-702:
-
Author: ASF GitHub Bot
Created on: 16/Jan/21 09:43
Start Date: 16/Jan/21 09:43
Worklog Time Spent: 10m
Work Description: boris-unckel commented on a change in pull request #187:
URL: https://github.com/apache/commons-io/pull/187#discussion_r558832744
##
File path:
src/test/java/org/apache/commons/io/FileUtilsDeleteDirectoryBaseTestCase.java
##
@@ -194,6 +194,29 @@ public void testDeleteParentSymlink2() throws Exception {
assertEquals(1, randomDirectory.list().length, "Contents of sym link
should not have been removed");
}
+@Test
+public void testDeleteInvalidLinks() throws Exception {
+File AFile = new File(top, "realParentDirA");
Review comment:
thnx, corrected.
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
Issue Time Tracking
---
Worklog Id: (was: 536757)
Time Spent: 1h 10m (was: 1h)
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] boris-unckel commented on a change in pull request #187: IO-702 FileUtils.forceDelete does not delete invalid links. Testcase …
boris-unckel commented on a change in pull request #187:
URL: https://github.com/apache/commons-io/pull/187#discussion_r558832744
##
File path:
src/test/java/org/apache/commons/io/FileUtilsDeleteDirectoryBaseTestCase.java
##
@@ -194,6 +194,29 @@ public void testDeleteParentSymlink2() throws Exception {
assertEquals(1, randomDirectory.list().length, "Contents of sym link
should not have been removed");
}
+@Test
+public void testDeleteInvalidLinks() throws Exception {
+File AFile = new File(top, "realParentDirA");
Review comment:
thnx, corrected.
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] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
[
https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266538#comment-17266538
]
Peter Lee commented on COMPRESS-562:
The attached test-services-1.1.0.apk I upload is the one I mentioned - I
removed the redundant bytes of zero and it could be successfully read with
ZipArchiveInputStream.
> ZipArchiveInputStream fails with unexpected record signature while
> ZipInputStream from java.util.zip succeeds
> -
>
> Key: COMPRESS-562
> URL: https://issues.apache.org/jira/browse/COMPRESS-562
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
> Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc
> 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X)
> on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>Reporter: Oleksii Khomchenko
>Priority: Major
> Attachments: apk.PNG, test-services-1.1.0.apk
>
>
> Thank you a lot for the library.
>
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record
> signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from
> [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0]
> via commons-compress:1.20 while java.util.zip reads it without the exception.
>
> {code:java}
> public class UnzipTestServicesSample {
> public static void main(String[] args) throws Exception {
> Path p = Paths.get("test-services-1.1.0.apk");
> System.out.println("\n=== java std zip ===\n");
> try (InputStream is = Files.newInputStream(p); ZipInputStream zis =
> new ZipInputStream(is)) {
> ZipEntry entry;
> while ((entry = zis.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> System.out.println("\n=== apache compress zip ===\n");
> try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais
> = new ZipArchiveInputStream(is)) {
> ArchiveEntry entry;
> while ((entry = ais.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> }
> }{code}
>
> zip -T says that archive is fine:
>
> {code:java}
> $ zip -T test-services-1.1.0.apk
> test of test-services-1.1.0.apk OK{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
[
https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lee updated COMPRESS-562:
---
Attachment: test-services-1.1.0.apk
> ZipArchiveInputStream fails with unexpected record signature while
> ZipInputStream from java.util.zip succeeds
> -
>
> Key: COMPRESS-562
> URL: https://issues.apache.org/jira/browse/COMPRESS-562
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
> Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc
> 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X)
> on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>Reporter: Oleksii Khomchenko
>Priority: Major
> Attachments: apk.PNG, test-services-1.1.0.apk
>
>
> Thank you a lot for the library.
>
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record
> signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from
> [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0]
> via commons-compress:1.20 while java.util.zip reads it without the exception.
>
> {code:java}
> public class UnzipTestServicesSample {
> public static void main(String[] args) throws Exception {
> Path p = Paths.get("test-services-1.1.0.apk");
> System.out.println("\n=== java std zip ===\n");
> try (InputStream is = Files.newInputStream(p); ZipInputStream zis =
> new ZipInputStream(is)) {
> ZipEntry entry;
> while ((entry = zis.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> System.out.println("\n=== apache compress zip ===\n");
> try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais
> = new ZipArchiveInputStream(is)) {
> ArchiveEntry entry;
> while ((entry = ais.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> }
> }{code}
>
> zip -T says that archive is fine:
>
> {code:java}
> $ zip -T test-services-1.1.0.apk
> test of test-services-1.1.0.apk OK{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
[
https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266536#comment-17266536
]
Peter Lee commented on COMPRESS-562:
Disclaimer : not familiar with zpk
I checked the apk file(test-services-1.1.0.apk) and found something strange :
There are 237 bytes of zero before the actual apk signing block.
!apk.PNG!
These redundant bytes of zero broke the read of apk signing block - that's why
we are throwing the unexpected record signature exception. And I can
successfully read this apk file with these bytes removed.
Accoarding to the [apk signing block
specification|[https://source.android.com/security/apksigning/v2]
,|https://source.android.com/security/apksigning/v2],]these bytes are not
mentioned. Please feel free to tell me if they are reasonable.
In short words, I believe the apk file is corrupted and could not be
successfully read using ZipArchiveInputStream(but can be read with ZipFile).
BTW : Why java standard zip(ZipInputStream) can successfully read this apk?
I check the code of ZipInputStream and found they didn't check if a Central
Directory File or APK signing block is met. They simply return null if the
signature is not the one of Local File Header. That's why they didn't report
any exceptions.
See also : [ZipInputStream in
OpenJDK|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L284]
> ZipArchiveInputStream fails with unexpected record signature while
> ZipInputStream from java.util.zip succeeds
> -
>
> Key: COMPRESS-562
> URL: https://issues.apache.org/jira/browse/COMPRESS-562
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
> Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc
> 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X)
> on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>Reporter: Oleksii Khomchenko
>Priority: Major
> Attachments: apk.PNG
>
>
> Thank you a lot for the library.
>
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record
> signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from
> [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0]
> via commons-compress:1.20 while java.util.zip reads it without the exception.
>
> {code:java}
> public class UnzipTestServicesSample {
> public static void main(String[] args) throws Exception {
> Path p = Paths.get("test-services-1.1.0.apk");
> System.out.println("\n=== java std zip ===\n");
> try (InputStream is = Files.newInputStream(p); ZipInputStream zis =
> new ZipInputStream(is)) {
> ZipEntry entry;
> while ((entry = zis.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> System.out.println("\n=== apache compress zip ===\n");
> try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais
> = new ZipArchiveInputStream(is)) {
> ArchiveEntry entry;
> while ((entry = ais.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> }
> }{code}
>
> zip -T says that archive is fine:
>
> {code:java}
> $ zip -T test-services-1.1.0.apk
> test of test-services-1.1.0.apk OK{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
[
https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lee updated COMPRESS-562:
---
Attachment: apk.PNG
> ZipArchiveInputStream fails with unexpected record signature while
> ZipInputStream from java.util.zip succeeds
> -
>
> Key: COMPRESS-562
> URL: https://issues.apache.org/jira/browse/COMPRESS-562
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
> Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc
> 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X)
> on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>Reporter: Oleksii Khomchenko
>Priority: Major
> Attachments: apk.PNG
>
>
> Thank you a lot for the library.
>
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record
> signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from
> [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0]
> via commons-compress:1.20 while java.util.zip reads it without the exception.
>
> {code:java}
> public class UnzipTestServicesSample {
> public static void main(String[] args) throws Exception {
> Path p = Paths.get("test-services-1.1.0.apk");
> System.out.println("\n=== java std zip ===\n");
> try (InputStream is = Files.newInputStream(p); ZipInputStream zis =
> new ZipInputStream(is)) {
> ZipEntry entry;
> while ((entry = zis.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> System.out.println("\n=== apache compress zip ===\n");
> try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais
> = new ZipArchiveInputStream(is)) {
> ArchiveEntry entry;
> while ((entry = ais.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> }
> }{code}
>
> zip -T says that archive is fine:
>
> {code:java}
> $ zip -T test-services-1.1.0.apk
> test of test-services-1.1.0.apk OK{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
[
https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266534#comment-17266534
]
Peter Lee commented on COMPRESS-562:
I tested to read this .apk with ZipFile and can be successfully read - maybe
you can try to read it with ZipFile instead of ZipArchiveInputStream.
> ZipArchiveInputStream fails with unexpected record signature while
> ZipInputStream from java.util.zip succeeds
> -
>
> Key: COMPRESS-562
> URL: https://issues.apache.org/jira/browse/COMPRESS-562
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
> Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc
> 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X)
> on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>Reporter: Oleksii Khomchenko
>Priority: Major
>
> Thank you a lot for the library.
>
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record
> signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from
> [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0]
> via commons-compress:1.20 while java.util.zip reads it without the exception.
>
> {code:java}
> public class UnzipTestServicesSample {
> public static void main(String[] args) throws Exception {
> Path p = Paths.get("test-services-1.1.0.apk");
> System.out.println("\n=== java std zip ===\n");
> try (InputStream is = Files.newInputStream(p); ZipInputStream zis =
> new ZipInputStream(is)) {
> ZipEntry entry;
> while ((entry = zis.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> System.out.println("\n=== apache compress zip ===\n");
> try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais
> = new ZipArchiveInputStream(is)) {
> ArchiveEntry entry;
> while ((entry = ais.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> }
> }{code}
>
> zip -T says that archive is fine:
>
> {code:java}
> $ zip -T test-services-1.1.0.apk
> test of test-services-1.1.0.apk OK{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
[
https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266530#comment-17266530
]
Peter Lee commented on COMPRESS-562:
This is associated with COMPRESS-455 and COMPRESS-461.
I'm trying to find out the problem. Considering I'm not familiar with APK
specification, a patch or PR is always welcome. :)
> ZipArchiveInputStream fails with unexpected record signature while
> ZipInputStream from java.util.zip succeeds
> -
>
> Key: COMPRESS-562
> URL: https://issues.apache.org/jira/browse/COMPRESS-562
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
> Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc
> 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X)
> on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>Reporter: Oleksii Khomchenko
>Priority: Major
>
> Thank you a lot for the library.
>
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record
> signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from
> [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0]
> via commons-compress:1.20 while java.util.zip reads it without the exception.
>
> {code:java}
> public class UnzipTestServicesSample {
> public static void main(String[] args) throws Exception {
> Path p = Paths.get("test-services-1.1.0.apk");
> System.out.println("\n=== java std zip ===\n");
> try (InputStream is = Files.newInputStream(p); ZipInputStream zis =
> new ZipInputStream(is)) {
> ZipEntry entry;
> while ((entry = zis.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> System.out.println("\n=== apache compress zip ===\n");
> try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais
> = new ZipArchiveInputStream(is)) {
> ArchiveEntry entry;
> while ((entry = ais.getNextEntry()) != null) {
> System.out.println("entry: " + entry.getName());
> }
> }
> }
> }{code}
>
> zip -T says that archive is fine:
>
> {code:java}
> $ zip -T test-services-1.1.0.apk
> test of test-services-1.1.0.apk OK{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
