[jira] [Resolved] (JEXL-424) Permission error after upgraded to JDK 21
[
https://issues.apache.org/jira/browse/JEXL-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-424.
Resolution: Fixed
Code was indeed dependent on permission lookup order since it was only checking
the permission cache; fix is to compute permission fully on a 'get' (if not
cached).
That being said, the new framework
org.apache.commons.jexl3.introspection.JexlPermissions is now the preferred way
to secure applications and restrict class/method/fields visibility.
Commit
[78b3dd9|https://github.com/apache/commons-jexl/commit/78b3dd90f07d86531c8c99f6f9b5bea00bea8205]
> Permission error after upgraded to JDK 21
> -
>
> Key: JEXL-424
> URL: https://issues.apache.org/jira/browse/JEXL-424
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {code:java}
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(Map.class.getName(), true, true, true, true);
> ...
> String jexlCode = "x.foo = 'bar';"
> JexlEngine engine =
> new Engine(
> new JexlBuilder()
> .sandbox(sandbox)
> .safe(false)
> .strict(true));
> Map vars = new LinkedHashMap<>();
> vars.put("x", new LinkedHashMap<>());
> engine.createScript(jexlCode).execute(new MapContext(vars)); {code}
> The code is ok with JDK11, but caused an error "undefined property 'foo'"
> with JDK21.
>
> I did some debug and found the problem is
> JDK11: LinkedHashMap implements Map
> JDK21: LinkedHashMap implements SequencedMap extends Map
> and from
> [JexlSandbox.java#L540|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/introspection/JexlSandbox.java#L540]]
> {code:java}
> for (final Class inter : clazz.getInterfaces()) {
> permissions = sandbox.get(inter.getName());
> if (permissions != null) {
> if (permissions.isInheritable()) {
> break;
> }
> permissions = null;
> }
> } {code}
> sandbox only checks the direct interfaces but not check it's super interface,
> but for class permission check, it looks into its parents, is it by design or
> a bug?
>
> And also because which checking permission of class, it does not check it's
> interface's permission, the result of class is not stable in case parent
> class has permission from it's interface.
> for example:
> {code:java}
> interface I{}
> static class A implements I{}
> static class B extends A{}
> @Test
> void testPermission() {
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(I.class.getName(), true, true, true, false);
> System.out.println("permission A=" +
> sandbox.get(A.class.getName()).write());
> System.out.println("permission B=" +
> sandbox.get(B.class.getName()).write());
> }
> {code}
> result is
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> permission
> B=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> but if checking B befoer A, the result is
> permission B=org.apache.commons.jexl3.introspection.JexlSandbox$2@6c1832aa
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@47ad69f7
>
> Maybe we need to travel the whole inheritance tree and also need a merge
> policy for multiple permission definitions?
>
> BTW, what is the release date for next version? thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-424) Permission error after upgraded to JDK 21
[
https://issues.apache.org/jira/browse/JEXL-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-424:
---
Assignee: Henri Biestro
> Permission error after upgraded to JDK 21
> -
>
> Key: JEXL-424
> URL: https://issues.apache.org/jira/browse/JEXL-424
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> {code:java}
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(Map.class.getName(), true, true, true, true);
> ...
> String jexlCode = "x.foo = 'bar';"
> JexlEngine engine =
> new Engine(
> new JexlBuilder()
> .sandbox(sandbox)
> .safe(false)
> .strict(true));
> Map vars = new LinkedHashMap<>();
> vars.put("x", new LinkedHashMap<>());
> engine.createScript(jexlCode).execute(new MapContext(vars)); {code}
> The code is ok with JDK11, but caused an error "undefined property 'foo'"
> with JDK21.
>
> I did some debug and found the problem is
> JDK11: LinkedHashMap implements Map
> JDK21: LinkedHashMap implements SequencedMap extends Map
> and from
> [JexlSandbox.java#L540|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/introspection/JexlSandbox.java#L540]]
> {code:java}
> for (final Class inter : clazz.getInterfaces()) {
> permissions = sandbox.get(inter.getName());
> if (permissions != null) {
> if (permissions.isInheritable()) {
> break;
> }
> permissions = null;
> }
> } {code}
> sandbox only checks the direct interfaces but not check it's super interface,
> but for class permission check, it looks into its parents, is it by design or
> a bug?
>
> And also because which checking permission of class, it does not check it's
> interface's permission, the result of class is not stable in case parent
> class has permission from it's interface.
> for example:
> {code:java}
> interface I{}
> static class A implements I{}
> static class B extends A{}
> @Test
> void testPermission() {
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(I.class.getName(), true, true, true, false);
> System.out.println("permission A=" +
> sandbox.get(A.class.getName()).write());
> System.out.println("permission B=" +
> sandbox.get(B.class.getName()).write());
> }
> {code}
> result is
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> permission
> B=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> but if checking B befoer A, the result is
> permission B=org.apache.commons.jexl3.introspection.JexlSandbox$2@6c1832aa
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@47ad69f7
>
> Maybe we need to travel the whole inheritance tree and also need a merge
> policy for multiple permission definitions?
>
> BTW, what is the release date for next version? thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-424) Permission error after upgraded to JDK 21
[
https://issues.apache.org/jira/browse/JEXL-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-424:
---
Fix Version/s: 3.4.1
> Permission error after upgraded to JDK 21
> -
>
> Key: JEXL-424
> URL: https://issues.apache.org/jira/browse/JEXL-424
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {code:java}
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(Map.class.getName(), true, true, true, true);
> ...
> String jexlCode = "x.foo = 'bar';"
> JexlEngine engine =
> new Engine(
> new JexlBuilder()
> .sandbox(sandbox)
> .safe(false)
> .strict(true));
> Map vars = new LinkedHashMap<>();
> vars.put("x", new LinkedHashMap<>());
> engine.createScript(jexlCode).execute(new MapContext(vars)); {code}
> The code is ok with JDK11, but caused an error "undefined property 'foo'"
> with JDK21.
>
> I did some debug and found the problem is
> JDK11: LinkedHashMap implements Map
> JDK21: LinkedHashMap implements SequencedMap extends Map
> and from
> [JexlSandbox.java#L540|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/introspection/JexlSandbox.java#L540]]
> {code:java}
> for (final Class inter : clazz.getInterfaces()) {
> permissions = sandbox.get(inter.getName());
> if (permissions != null) {
> if (permissions.isInheritable()) {
> break;
> }
> permissions = null;
> }
> } {code}
> sandbox only checks the direct interfaces but not check it's super interface,
> but for class permission check, it looks into its parents, is it by design or
> a bug?
>
> And also because which checking permission of class, it does not check it's
> interface's permission, the result of class is not stable in case parent
> class has permission from it's interface.
> for example:
> {code:java}
> interface I{}
> static class A implements I{}
> static class B extends A{}
> @Test
> void testPermission() {
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(I.class.getName(), true, true, true, false);
> System.out.println("permission A=" +
> sandbox.get(A.class.getName()).write());
> System.out.println("permission B=" +
> sandbox.get(B.class.getName()).write());
> }
> {code}
> result is
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> permission
> B=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> but if checking B befoer A, the result is
> permission B=org.apache.commons.jexl3.introspection.JexlSandbox$2@6c1832aa
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@47ad69f7
>
> Maybe we need to travel the whole inheritance tree and also need a merge
> policy for multiple permission definitions?
>
> BTW, what is the release date for next version? thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NUMBERS-206) Selection API
[
https://issues.apache.org/jira/browse/NUMBERS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855978#comment-17855978
]
Alex Herbert commented on NUMBERS-206:
--
h1. Performance on Different Data Types
I copied the current double select implementation for other primitive types
that cannot be easily sorted using a histogram (i.e. char, short and byte).
These were tested using the BM data on length 5:
!SelectDataType.png|width=800,height=600!
There is very little difference between the float and double types; float is
marginally faster. The integer types long and int are noticeably faster (around
20-25%).
This difference is approximately the same when selection is repeated using
uniform random data, for example:
||k||double||float||long||int||
|100|11395639641|11247566058|8978986808|8784180316|
|Relative| 1.0|0.987|0.787|0.771|
h2. Use Cases
Note that using the double implementation will be able to provide the same
result for all other datatypes if they are converted to a double, with the
exception of any long data that exceeds 53-bits of precision. The downsides
are: a (small) performance loss; and an increase in memory consumption. Memory
overhead will vary based on whether the original data is changed to be stored
as a double, or copied to a double array for selection.
Before adding support for other data types, the use cases should be considered.
Currently selection is used in the Statistics package for quantile estimation
of data. Typical numeric analysis would use a double data value. The Statistics
descriptive package also supports the other primitive types used in Java
streams (long and int). If numeric analysis is being performed on discrete data
then the input could be a long or an int. Note the Statistics distributions
package implements discrete distributions using the int primitive data type.
The use of int and smaller primitive types for numeric data is typical for
images (e.g. 16-bit or 8-bit image data). The use of a long data type is
unnecessary except for extremely large counts. This may occur for example when
analysing file sizes for millions of files. However a file of size 53-bits
would be 8+ petabytes. This is an unrealistic size for a single file; a large
datastore may exceed this size as a total. Since selection would be used on
single elements then partial sorting of long array data of file sizes could be
performed using a double.
Due to the improved performance over a double, and possible application to
various discrete data it may be useful to add selection support for int[] data
(and a matching Quantile implementation).
> Selection API
> -
>
> Key: NUMBERS-206
> URL: https://issues.apache.org/jira/browse/NUMBERS-206
> Project: Commons Numbers
> Issue Type: New Feature
> Components: arrays
>Reporter: Alex Herbert
>Priority: Major
> Fix For: 1.2
>
> Attachments: SelectDataType.png
>
>
> Create a selection API to select the k-th largest element in an array. This
> places at k the same value that would be at k in a fully sorted array.
> {code:java}
> public final class Selection {
> public static void select(double[] a, int k);
> public static void select(double[] a, int from, int to, int k);
> public static void select(double[] a, int[] k);
> public static void select(double[] a, int from, int to, int[] k);
> // Extend to other primitive data types that are not easily sorted (e.g.
> long, float, int)
> {code}
> Note: This API will support multiple points (int[] k) for use in quantile
> estimation of array data by interpolation of neighbouring values (see
> STATISTICS-85).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [CLI-336] Deprecation not always reported [commons-cli]
garydgregory commented on PR #284: URL: https://github.com/apache/commons-cli/pull/284#issuecomment-2176356452 @Claudenw Good luck with the move -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IO-856) ListFiles should not fail on vanishing files
[
https://issues.apache.org/jira/browse/IO-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855970#comment-17855970
]
Gary D. Gregory commented on IO-856:
[~thomas.hart...@gmail.com]
The build passes for all Java LTS versions on GitHub CI:
[https://github.com/apache/commons-io/actions]
So where is the test failing "at first assertion"?
The best path forward is to provide a PR on GitHub with a JUnit test that shows
the failure.
"I do not understand what the problem is to copy my code into it."
The code you provided is not a unit test, it's a standalone program that makes
no assertions; it also seems to be nondeterministic.
> ListFiles should not fail on vanishing files
>
>
> Key: IO-856
> URL: https://issues.apache.org/jira/browse/IO-856
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.16.1
>Reporter: Thomas Hartwig
>Assignee: Gary D. Gregory
>Priority: Major
>
> ListFiles crashes when vanishing files are involved while listing, ListFiles
> should simply list, the application should care of if files are not existent
> any more:
>
> java.io.UncheckedIOException: java.nio.file.NoSuchFileException:
> /tmp/20b50a15-b84e-4a9a-953e-223452dac994/a914fa55-50f7-4de0-8ca6-1fd84f10b29a.png
> at
> java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:87)
> at
> java.base/java.nio.file.FileTreeIterator.hasNext(FileTreeIterator.java:103)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1845)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
> at
> org.apache.commons.io@2.16.1/org.apache.commons.io.FileUtils.toList(FileUtils.java:3025)
> at
> org.apache.commons.io@2.16.1/org.apache.commons.io.FileUtils.listFiles(FileUtils.java:2314)
> at com.itth.test/test.ApacheBug.lambda$main$1(ApacheBug.java:39)
> at java.base/java.lang.Thread.run(Thread.java:842)
> Caused by: java.nio.file.NoSuchFileException:
> /tmp/20b50a15-b84e-4a9a-953e-223452dac994/a914fa55-50f7-4de0-8ca6-1fd84f10b29a.png
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:148)
> at
> java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
> at java.base/java.nio.file.Files.readAttributes(Files.java:1851)
> at
> java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:226)
> at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:277)
> at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:374)
> at
> java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:83)
> ... 12 more
>
> Use this to reproduce:
>
> package test;
> import org.apache.commons.io.FileUtils;
> import java.io.BufferedOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.nio.charset.StandardCharsets;
> import java.nio.file.Path;
> import java.util.Collection;
> import java.util.UUID;
> public class ApacheBug {
> public static void main(String[] args) {
> // create random directory in tmp, create the directory if it does not exist
> final File dir = FileUtils.getTempDirectory();
> if (!dir.exists()) {
> if (!dir.mkdirs()) {
> throw new RuntimeException("could not create image file path: " +
> dir.getAbsolutePath());
> }
> }
> // create random file in the directory
> new Thread(() -> {
> try {
> while (true) {
> final File file = Path.of(dir.getAbsolutePath(), UUID.randomUUID().toString()
> + ".png").toFile();
> new BufferedOutputStream(new
> FileOutputStream(file)).write("TEST".getBytes(StandardCharsets.UTF_8));
> file.delete();
> }
> } catch (IOException e) {
> e.printStackTrace();
> }
> }).start();
> new Thread(() -> {
> try {
> while (true) {
> final Collection files = FileUtils.listFiles(dir, new
Re: [PR] [CLI-336] Deprecation not always reported [commons-cli]
Claudenw commented on PR #284: URL: https://github.com/apache/commons-cli/pull/284#issuecomment-2176303412 I am traveling and moving over thenext two weeks. I hope to get to this later this week, time permitting. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NUMBERS-206) Selection API
[
https://issues.apache.org/jira/browse/NUMBERS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert updated NUMBERS-206:
-
Attachment: SelectDataType.png
> Selection API
> -
>
> Key: NUMBERS-206
> URL: https://issues.apache.org/jira/browse/NUMBERS-206
> Project: Commons Numbers
> Issue Type: New Feature
> Components: arrays
>Reporter: Alex Herbert
>Priority: Major
> Fix For: 1.2
>
> Attachments: SelectDataType.png
>
>
> Create a selection API to select the k-th largest element in an array. This
> places at k the same value that would be at k in a fully sorted array.
> {code:java}
> public final class Selection {
> public static void select(double[] a, int k);
> public static void select(double[] a, int from, int to, int k);
> public static void select(double[] a, int[] k);
> public static void select(double[] a, int from, int to, int[] k);
> // Extend to other primitive data types that are not easily sorted (e.g.
> long, float, int)
> {code}
> Note: This API will support multiple points (int[] k) for use in quantile
> estimation of array data by interpolation of neighbouring values (see
> STATISTICS-85).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump maven.dependency.version from 3.9.7 to 3.9.8 [commons-release-plugin]
garydgregory merged PR #290: URL: https://github.com/apache/commons-release-plugin/pull/290 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.commons:commons-collections4 from 4.5.0-M1 to 4.5.0-M2 [commons-release-plugin]
garydgregory merged PR #289: URL: https://github.com/apache/commons-release-plugin/pull/289 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.commons:commons-parent from 70 to 71 [commons-beanutils]
garydgregory merged PR #254: URL: https://github.com/apache/commons-beanutils/pull/254 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IO-856) ListFiles should not fail on vanishing files
[
https://issues.apache.org/jira/browse/IO-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855935#comment-17855935
]
Thomas Hartwig commented on IO-856:
---
Hi Gary,
the test you provided has obvious errors and is failing already at first
assertion. I do not understand what the problem is to copy my code into it.
I tested all the latest JDK for 17 and 19. Nothing works.
BR
> ListFiles should not fail on vanishing files
>
>
> Key: IO-856
> URL: https://issues.apache.org/jira/browse/IO-856
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.16.1
>Reporter: Thomas Hartwig
>Assignee: Gary D. Gregory
>Priority: Major
>
> ListFiles crashes when vanishing files are involved while listing, ListFiles
> should simply list, the application should care of if files are not existent
> any more:
>
> java.io.UncheckedIOException: java.nio.file.NoSuchFileException:
> /tmp/20b50a15-b84e-4a9a-953e-223452dac994/a914fa55-50f7-4de0-8ca6-1fd84f10b29a.png
> at
> java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:87)
> at
> java.base/java.nio.file.FileTreeIterator.hasNext(FileTreeIterator.java:103)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1845)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
> at
> org.apache.commons.io@2.16.1/org.apache.commons.io.FileUtils.toList(FileUtils.java:3025)
> at
> org.apache.commons.io@2.16.1/org.apache.commons.io.FileUtils.listFiles(FileUtils.java:2314)
> at com.itth.test/test.ApacheBug.lambda$main$1(ApacheBug.java:39)
> at java.base/java.lang.Thread.run(Thread.java:842)
> Caused by: java.nio.file.NoSuchFileException:
> /tmp/20b50a15-b84e-4a9a-953e-223452dac994/a914fa55-50f7-4de0-8ca6-1fd84f10b29a.png
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:148)
> at
> java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
> at java.base/java.nio.file.Files.readAttributes(Files.java:1851)
> at
> java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:226)
> at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:277)
> at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:374)
> at
> java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:83)
> ... 12 more
>
> Use this to reproduce:
>
> package test;
> import org.apache.commons.io.FileUtils;
> import java.io.BufferedOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.nio.charset.StandardCharsets;
> import java.nio.file.Path;
> import java.util.Collection;
> import java.util.UUID;
> public class ApacheBug {
> public static void main(String[] args) {
> // create random directory in tmp, create the directory if it does not exist
> final File dir = FileUtils.getTempDirectory();
> if (!dir.exists()) {
> if (!dir.mkdirs()) {
> throw new RuntimeException("could not create image file path: " +
> dir.getAbsolutePath());
> }
> }
> // create random file in the directory
> new Thread(() -> {
> try {
> while (true) {
> final File file = Path.of(dir.getAbsolutePath(), UUID.randomUUID().toString()
> + ".png").toFile();
> new BufferedOutputStream(new
> FileOutputStream(file)).write("TEST".getBytes(StandardCharsets.UTF_8));
> file.delete();
> }
> } catch (IOException e) {
> e.printStackTrace();
> }
> }).start();
> new Thread(() -> {
> try {
> while (true) {
> final Collection files = FileUtils.listFiles(dir, new String[]\{"png"},
> true);
> System.out.println(files.size());
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }).start();
> try {
> Thread.sleep(1);
> } catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> }
> }
> }
>
>
--
This message
[jira] [Updated] (COLLECTIONS-542) AbstractHashedMap should not extend AbstractMap anymore
[ https://issues.apache.org/jira/browse/COLLECTIONS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated COLLECTIONS-542: Fix Version/s: 4.5.0 (was: 4.5.0-M2) > AbstractHashedMap should not extend AbstractMap anymore > --- > > Key: COLLECTIONS-542 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-542 > Project: Commons Collections > Issue Type: Task >Affects Versions: 4.0 >Reporter: Thomas Neidhart >Priority: Minor > Fix For: 5.0, 4.5.0 > > > As described in the javadoc of AbstractHashedMap, the inheritance of > AbstractMap should have been removed in the 4.0 release. > This has been forgotten. Removal of the inheritance does not seem to be > possible for the 4.x branch, so we should at least correct the javadoc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-551) Move Iterable related methods from CollectionUtils to IterableUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated COLLECTIONS-551: Fix Version/s: 4.5.0 (was: 4.5.0-M2) > Move Iterable related methods from CollectionUtils to IterableUtils > --- > > Key: COLLECTIONS-551 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-551 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Thomas Neidhart >Priority: Major > Fix For: 5.0, 4.5.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IO-857) PathUtils.cleanDirectory method does not erase subdirectories
[ https://issues.apache.org/jira/browse/IO-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855911#comment-17855911 ] Dmitry edited comment on IO-857 at 6/18/24 12:24 PM: - I've read it, I just don't understand the use-case for this behavior. That leaves a bunch of empty subdirectories. PathUtils.deleteDirectory, erases the directory itself. And it may not be possible to recreate it on Linux systems where special rights to directories are set. And as I wrote earlier, FileUtils.cleanDirectory does not have such a problem was (Author: JIRAUSER305861): I've read it, I just don't understand the use-case for this behavior. That leaves a bunch of empty subdirectories. Path Utils.DeleteDirectory, erases the directory itself. And it may not be possible to recreate it on Linux systems where special rights to directories are set. And as I wrote earlier, FileUtils.cleanDirectory does not have such a problem > PathUtils.cleanDirectory method does not erase subdirectories > - > > Key: IO-857 > URL: https://issues.apache.org/jira/browse/IO-857 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.16.1 >Reporter: Dmitry >Priority: Minor > > The PathUtils.cleanDirectory method does not erase subdirectories. Only the > files in them. The FileUtils.cleanDirectory method erases everything except > the directory itself, and this is the expected behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IO-857) PathUtils.cleanDirectory method does not erase subdirectories
[ https://issues.apache.org/jira/browse/IO-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry reopened IO-857: --- Please explain why there is such a difference in implementation between PathUilts and FileUtils > PathUtils.cleanDirectory method does not erase subdirectories > - > > Key: IO-857 > URL: https://issues.apache.org/jira/browse/IO-857 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.16.1 >Reporter: Dmitry >Priority: Minor > > The PathUtils.cleanDirectory method does not erase subdirectories. Only the > files in them. The FileUtils.cleanDirectory method erases everything except > the directory itself, and this is the expected behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-857) PathUtils.cleanDirectory method does not erase subdirectories
[ https://issues.apache.org/jira/browse/IO-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855911#comment-17855911 ] Dmitry commented on IO-857: --- I've read it, I just don't understand the use-case for this behavior. That leaves a bunch of empty subdirectories. Path Utils.DeleteDirectory, erases the directory itself. And it may not be possible to recreate it on Linux systems where special rights to directories are set. And as I wrote earlier, FileUtils.cleanDirectory does not have such a problem > PathUtils.cleanDirectory method does not erase subdirectories > - > > Key: IO-857 > URL: https://issues.apache.org/jira/browse/IO-857 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.16.1 >Reporter: Dmitry >Priority: Minor > > The PathUtils.cleanDirectory method does not erase subdirectories. Only the > files in them. The FileUtils.cleanDirectory method erases everything except > the directory itself, and this is the expected behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-856) ListFiles should not fail on vanishing files
[
https://issues.apache.org/jira/browse/IO-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855906#comment-17855906
]
Gary D. Gregory commented on IO-856:
[~thomas.hart...@gmail.com]
Ping?
> ListFiles should not fail on vanishing files
>
>
> Key: IO-856
> URL: https://issues.apache.org/jira/browse/IO-856
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.16.1
>Reporter: Thomas Hartwig
>Assignee: Gary D. Gregory
>Priority: Major
>
> ListFiles crashes when vanishing files are involved while listing, ListFiles
> should simply list, the application should care of if files are not existent
> any more:
>
> java.io.UncheckedIOException: java.nio.file.NoSuchFileException:
> /tmp/20b50a15-b84e-4a9a-953e-223452dac994/a914fa55-50f7-4de0-8ca6-1fd84f10b29a.png
> at
> java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:87)
> at
> java.base/java.nio.file.FileTreeIterator.hasNext(FileTreeIterator.java:103)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1845)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
> at
> org.apache.commons.io@2.16.1/org.apache.commons.io.FileUtils.toList(FileUtils.java:3025)
> at
> org.apache.commons.io@2.16.1/org.apache.commons.io.FileUtils.listFiles(FileUtils.java:2314)
> at com.itth.test/test.ApacheBug.lambda$main$1(ApacheBug.java:39)
> at java.base/java.lang.Thread.run(Thread.java:842)
> Caused by: java.nio.file.NoSuchFileException:
> /tmp/20b50a15-b84e-4a9a-953e-223452dac994/a914fa55-50f7-4de0-8ca6-1fd84f10b29a.png
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:148)
> at
> java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
> at java.base/java.nio.file.Files.readAttributes(Files.java:1851)
> at
> java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:226)
> at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:277)
> at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:374)
> at
> java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:83)
> ... 12 more
>
> Use this to reproduce:
>
> package test;
> import org.apache.commons.io.FileUtils;
> import java.io.BufferedOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.nio.charset.StandardCharsets;
> import java.nio.file.Path;
> import java.util.Collection;
> import java.util.UUID;
> public class ApacheBug {
> public static void main(String[] args) {
> // create random directory in tmp, create the directory if it does not exist
> final File dir = FileUtils.getTempDirectory();
> if (!dir.exists()) {
> if (!dir.mkdirs()) {
> throw new RuntimeException("could not create image file path: " +
> dir.getAbsolutePath());
> }
> }
> // create random file in the directory
> new Thread(() -> {
> try {
> while (true) {
> final File file = Path.of(dir.getAbsolutePath(), UUID.randomUUID().toString()
> + ".png").toFile();
> new BufferedOutputStream(new
> FileOutputStream(file)).write("TEST".getBytes(StandardCharsets.UTF_8));
> file.delete();
> }
> } catch (IOException e) {
> e.printStackTrace();
> }
> }).start();
> new Thread(() -> {
> try {
> while (true) {
> final Collection files = FileUtils.listFiles(dir, new String[]\{"png"},
> true);
> System.out.println(files.size());
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }).start();
> try {
> Thread.sleep(1);
> } catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> }
> }
> }
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IO-857) PathUtils.cleanDirectory method does not erase subdirectories
[ https://issues.apache.org/jira/browse/IO-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-857. Resolution: Information Provided [~ydmitrya] You must not have read the Javadoc: "Cleans a directory including subdirectories without deleting directories." If you want to delete directories, uses a "delete" method like "deleteDirectory", not a "clean" method. > PathUtils.cleanDirectory method does not erase subdirectories > - > > Key: IO-857 > URL: https://issues.apache.org/jira/browse/IO-857 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.16.1 >Reporter: Dmitry >Priority: Minor > > The PathUtils.cleanDirectory method does not erase subdirectories. Only the > files in them. The FileUtils.cleanDirectory method erases everything except > the directory itself, and this is the expected behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-857) PathUtils.cleanDirectory method does not erase subdirectories
Dmitry created IO-857: - Summary: PathUtils.cleanDirectory method does not erase subdirectories Key: IO-857 URL: https://issues.apache.org/jira/browse/IO-857 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.16.1 Reporter: Dmitry The PathUtils.cleanDirectory method does not erase subdirectories. Only the files in them. The FileUtils.cleanDirectory method erases everything except the directory itself, and this is the expected behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
