[jira] [Commented] (IO-808) FileUtils.moveFile, copyFile and others can throw undocumened IllegalArgumentException
[
https://issues.apache.org/jira/browse/IO-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849258#comment-17849258
]
Elliotte Rusty Harold commented on IO-808:
--
A commons library is not the place to litigate language design questions. Nor
is it a Kotlin library, It's a Java one, so I don't really see what the point
of the stack overflow thread is.
For good developer experience, it's essential that libraries follow the design,
idioms, and patterns of the language they're written for, in this case Java.
Breaking with established and deliberate Java practice on anything — not just
exceptions, but object construction, multithreading, access protection, package
naming, and a hundred other things — is a fatal and all too common flaw among
library maintainers who think they know better than the developers who designed
the language. Maybe they do, but it doesn't matter. Moving away from what
developers have learned to expect in a language leads directly to bugs and
developer pain.
Java libraries either use the Java language and its standard libraries,
including IOException and IllegalArgumentException, the way they were designed
to be used, or the library becomes hard to use and bug prone.
On exceptions in particular, see Section 10 of Effective Java, 3rd edition,
particularly Item 72: Favor the use of standard exceptions.
> FileUtils.moveFile, copyFile and others can throw undocumened
> IllegalArgumentException
> --
>
> Key: IO-808
> URL: https://issues.apache.org/jira/browse/IO-808
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.12.0
> Environment: Windows 10
>Reporter: Phil D
>Priority: Major
> Attachments: MakyAckyBreaky.java, TestMoveFileIAE.java
>
>
> Several of the functions in FileUtils are throwing undocumented
> IllegalArgumentException such as moveFile, copyFile and other locations.
> If the desire is to maintain backwards compatibility with the 1.4 branch for
> these functions, then the 2.12 (and 2.13) versions are throwing
> IllegalArgumentException in cases where 1.4 is not. In fact, it seems like
> 1.4 was coded to specifically avoid IllegalArgumentException and throws
> IOExceptions instead.
> There are several different cases where this is possible. In the most basic,
> I've attached TestMoveFileIAE, where this can be reproduced by simple running:
> {code:bash}
> mkdir one
> java -cp TestMoveFileIAE one two
> Exception in thread "main" java.lang.IllegalArgumentException: Parameter
> 'srcFile' is not a file: one
> at org.apache.commons.io.FileUtils.requireFile(FileUtils.java:2824)
> at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2395)
> at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:2374)
> at TestMoveFileIAE.main(TestMoveFileIAE.java:13)
> {code}
> In a less likely scenario (which is how I found this issue because this
> happened on a production system); If the srcFile is removed at a certain
> point during moveFile() execution then IllegalArgumentException is throws:
> https://github.com/apache/commons-io/blob/master/src/main/java/org/apache/commons/io/FileUtils.java#L2392
> {code:java}
> 2392public static void moveFile(final File srcFile, final File destFile,
> final CopyOption... copyOptions) throws IOException {
> 2393validateMoveParameters(srcFile, destFile); // checks srcFile.exists()
> /// srcFile deleted here!!!
> 2394requireFile(srcFile, "srcFile"); // checks srcFile.isFile()
> and throws IAE
> 2395requireAbsent(destFile, "destFile");
> /// srcFile could also be deleted here
> 2396... // renameTo or copyFile() which also calls requireCopyFile() and
> requireFile()
> {code}
> This pattern of calling validateMoveParameters() and requireFile() will throw
> IllegalArgumentException every when the srcFile is removed between between
> validateMoveParameters() and requireFile() or requireFileCopy() and
> requireFile()
> Preferably, it would be best if the 2.x versions of FileUtils were backwards
> compatible with 1.x and IllegalArgumentException would not be thrown, but
> IOException (or one of its derivatives) would be. IAE is an unchecked
> exception and can cause unexpected issues.
> I would also suggest that unit tests be created to ensure that these
> functions behave as expected in error conditions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-835) FileOrigin == PathOrigin
[ https://issues.apache.org/jira/browse/IO-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830295#comment-17830295 ] Elliotte Rusty Harold commented on IO-835: -- But File and Path really are the same thing, or rather they're two different APIs created years apart to represent exactly the same thing. While a file and path are different java.io.File and java.nio.file.Path both represent paths, not files, names notwithstanding. > FileOrigin == PathOrigin > > > Key: IO-835 > URL: https://issues.apache.org/jira/browse/IO-835 > Project: Commons IO > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > FileOrigin and PathOrigin are the same thing. They both represent a file in > the file system. Two classes really aren't needed here, any more than we need > two classes for StringOrigin and StringBuilderOrigin. Instead we need two > constructors, one of which takes a File and one of which takes a Path. > Or at the very least make one a subclass of the other. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-598) NullPointerException in ZipArchiveInputStream.getCompressedCount()
[
https://issues.apache.org/jira/browse/COMPRESS-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820044#comment-17820044
]
Elliotte Rusty Harold commented on COMPRESS-598:
I vote fro throwing a better exception
> NullPointerException in ZipArchiveInputStream.getCompressedCount()
> --
>
> Key: COMPRESS-598
> URL: https://issues.apache.org/jira/browse/COMPRESS-598
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Dominik Stadler
>Priority: Critical
> Labels: NullPointerException, fuzzer, npe
> Attachments: Crash_f2efd9eaeb86cda597d07b5e3c3d81363633c2da.java,
> crash-f2efd9eaeb86cda597d07b5e3c3d81363633c2da
>
>
> While fuzzing Apache POI, I discovered a case which can trigger a
> NullPointerException in ZipArchiveInputStream.getCompressedCount().
> The attached test-application and file are a fairly minimal reproducing
> testcase.
> Put the java file into src/test/java and the file into /src/test/resources
> Running it then produces the following:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getCompressedCount(ZipArchiveInputStream.java:559)
> at
> Crash_f2efd9eaeb86cda597d07b5e3c3d81363633c2da.main(Crash_f2efd9eaeb86cda597d07b5e3c3d81363633c2da.java:26)
> {noformat}
>
> Happens with 1.21 as well as latest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (COMPRESS-665) deprecate CharsetNames
Elliotte Rusty Harold created COMPRESS-665: -- Summary: deprecate CharsetNames Key: COMPRESS-665 URL: https://issues.apache.org/jira/browse/COMPRESS-665 Project: Commons Compress Issue Type: Improvement Reporter: Elliotte Rusty Harold This is old Java 1.4 code that hasn't been needed since Java 1.6. It just wraps StandardCharsets and everything in it can be easily inlined. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-848) FileUtil.createTempFileWithLines swallows exceptions
[ https://issues.apache.org/jira/browse/IO-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818593#comment-17818593 ] Elliotte Rusty Harold commented on IO-848: -- I think you're right. Looks like Eclipse autocomplete pulled in a completely different FileUtil class from some unrelated project and I wasn't paying close enough attention. > FileUtil.createTempFileWithLines swallows exceptions > > > Key: IO-848 > URL: https://issues.apache.org/jira/browse/IO-848 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Critical > > Although this method is declared to throw IOException, it doesn't do so when > writing the file as it uses a PrintWriter. > Probably worth thinking about how this method handles encoding too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-639) ReversedLinesFileReader does not read first line if it's empty
[
https://issues.apache.org/jira/browse/IO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818513#comment-17818513
]
Elliotte Rusty Harold commented on IO-639:
--
slightly simpler case that repros this is a file that contains a line break and
nothing else:
{noformat}
@Test
public void testLineBreakOnly() throws IOException, URISyntaxException {
File file = File.createTempFile("foo", "txt");
Files.write(file.toPath(), "\n".getBytes(StandardCharsets.ISO_8859_1));
try (ReversedLinesFileReader reversedLinesFileReader = new
ReversedLinesFileReader(file, BLOCK_SIZE,
StandardCharsets.ISO_8859_1.name())) {
assertEqualsAndNoLineBreaks("", reversedLinesFileReader.readLine());
} finally {
file.delete();
}
}
{noformat}
> ReversedLinesFileReader does not read first line if it's empty
> --
>
> Key: IO-639
> URL: https://issues.apache.org/jira/browse/IO-639
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Mashrur Mia
>Priority: Minor
>
> ReversedLinesFileReader does not seem to read the first if the the line is
> empty. Consider the content of a file:
> {code}
> \n
> test\n
> {code}
> where the first line is simple a newline character. If
> ReversedLinesFileReader is used to read the file in reverse, then only the
> 2nd line is read - in the subsequent call, {{::readLine}} return null.
> Here is a Java test that was tried:
> {code:java}
> class ReversedFileReaderTest {
> @ParameterizedTest
> @MethodSource("contentAndExpectedProvider")
> void testReadLineInReverse_givenTwoLines(String content, List
> expected)
> throws IOException {
> File file = Files.newTemporaryFile();
> java.nio.file.Files.write(Path.of(file.getPath()),
> content.getBytes());
> List lines = new ArrayList<>();
> try (ReversedLinesFileReader fileReader = new
> ReversedLinesFileReader(file,
> StandardCharsets.UTF_8)) {
> String line;
> while ((line = fileReader.readLine()) != null) {
> lines.add(line);
> }
> }
> assertThat(lines).isEqualTo(expected);
> }
> static Stream contentAndExpectedProvider() {
> return Stream.of(
> arguments("the\ntest\n", Arrays.asList("test", "the")),
> arguments("\ntest\n", Arrays.asList("test", "")),
> arguments("\n\ntest\n", Arrays.asList("test", "", "")),
> arguments("\n\n", Arrays.asList("", "")),
> arguments("\n", Arrays.asList(""))
> );
> }
> }
> {code}
> Only the first test case runs. All the last four fails
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IO-848) FileUtil.createTempFileWithLines swallows exceptions
Elliotte Rusty Harold created IO-848: Summary: FileUtil.createTempFileWithLines swallows exceptions Key: IO-848 URL: https://issues.apache.org/jira/browse/IO-848 Project: Commons IO Issue Type: Bug Reporter: Elliotte Rusty Harold Although this method is declared to throw IOException, it doesn't do so when writing the file as it uses a PrintWriter. Probably worth thinking about how this method handles encoding too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-639) ReversedLinesFileReader does not read first line if it's empty
[
https://issues.apache.org/jira/browse/IO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818508#comment-17818508
]
Elliotte Rusty Harold commented on IO-639:
--
I can confirm this issue. I do not yet have a fix for it. The code is too
clever by half.
> ReversedLinesFileReader does not read first line if it's empty
> --
>
> Key: IO-639
> URL: https://issues.apache.org/jira/browse/IO-639
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Mashrur Mia
>Priority: Minor
>
> ReversedLinesFileReader does not seem to read the first if the the line is
> empty. Consider the content of a file:
> {code}
> \n
> test\n
> {code}
> where the first line is simple a newline character. If
> ReversedLinesFileReader is used to read the file in reverse, then only the
> 2nd line is read - in the subsequent call, {{::readLine}} return null.
> Here is a Java test that was tried:
> {code:java}
> class ReversedFileReaderTest {
> @ParameterizedTest
> @MethodSource("contentAndExpectedProvider")
> void testReadLineInReverse_givenTwoLines(String content, List
> expected)
> throws IOException {
> File file = Files.newTemporaryFile();
> java.nio.file.Files.write(Path.of(file.getPath()),
> content.getBytes());
> List lines = new ArrayList<>();
> try (ReversedLinesFileReader fileReader = new
> ReversedLinesFileReader(file,
> StandardCharsets.UTF_8)) {
> String line;
> while ((line = fileReader.readLine()) != null) {
> lines.add(line);
> }
> }
> assertThat(lines).isEqualTo(expected);
> }
> static Stream contentAndExpectedProvider() {
> return Stream.of(
> arguments("the\ntest\n", Arrays.asList("test", "the")),
> arguments("\ntest\n", Arrays.asList("test", "")),
> arguments("\n\ntest\n", Arrays.asList("test", "", "")),
> arguments("\n\n", Arrays.asList("", "")),
> arguments("\n", Arrays.asList(""))
> );
> }
> }
> {code}
> Only the first test case runs. All the last four fails
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-832) Update first section of home page
[ https://issues.apache.org/jira/browse/IO-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817698#comment-17817698 ] Elliotte Rusty Harold commented on IO-832: -- This is resolved now > Update first section of home page > - > > Key: IO-832 > URL: https://issues.apache.org/jira/browse/IO-832 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > Attachments: image-2023-12-29-13-43-31-816.png > > > !image-2023-12-29-13-43-31-816.png! > 1. There are more than six areas. > 2. All the links for sub-packages end up on the > https://commons.apache.org/proper/commons-io/apidocs/index.html page even > though the link tries to go deeper -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-832) Update first section of home page
[ https://issues.apache.org/jira/browse/IO-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817581#comment-17817581 ] Elliotte Rusty Harold commented on IO-832: -- Links go to https://commons.apache.org/proper/commons-io/apidocs/index.html?org/apache/commons/io/serialization/package-summary.html but should go to https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/serialization/package-summary.html Might be incorrect relative links > Update first section of home page > - > > Key: IO-832 > URL: https://issues.apache.org/jira/browse/IO-832 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > Attachments: image-2023-12-29-13-43-31-816.png > > > !image-2023-12-29-13-43-31-816.png! > 1. There are more than six areas. > 2. All the links for sub-packages end up on the > https://commons.apache.org/proper/commons-io/apidocs/index.html page even > though the link tries to go deeper -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-152) Helper class that redirects OutputStream to Log
[
https://issues.apache.org/jira/browse/LOGGING-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816438#comment-17816438
]
Elliotte Rusty Harold commented on LOGGING-152:
---
Generally logs are redirected where the program is invoked in the shell, not
inside the program itself. That's implicit in how a lot of designs work.
Libraries that accept an OutputStream as a target for debug messages are
uncommon at best. I can't say I've ever seen one. The point of logging
libraries is that the logger configuration is applied to loggers and libraries
write their messages to the logger, not to an arbitrary output stream. The
logger can be controlled by library clients without having to pollute the API
with logger objects. Thinking about it now, I'm not sure it had to be that way,
but it is what the ecosystem seems to have settled on for multiple decades now.
> Helper class that redirects OutputStream to Log
> ---
>
> Key: LOGGING-152
> URL: https://issues.apache.org/jira/browse/LOGGING-152
> Project: Commons Logging
> Issue Type: Improvement
>Affects Versions: 1.1.1
>Reporter: Dmitry Katsubo
>Priority: Major
> Attachments: LoggingOutputStream.java
>
>
> Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for
> debug messages to be printed to. The attached class acts as a bridge between
> {{OutputStream}} and {{org.apache.commons.logging.Log}}.
> Example of usage:
> {code}
> PrintStream loggingPrintStream = new PrintStream(new
> LoggingOutputStream(logger, LoggingOutputStream.LogLevel.INFO, "[XJC] "));
> com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
> {code}
> Also has some overlap with LOGGING-110.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1653) API visibility issues: Internal types are exposed in public API
[
https://issues.apache.org/jira/browse/LANG-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816436#comment-17816436
]
Elliotte Rusty Harold commented on LANG-1653:
-
Good catch. I'm not sure what to do here. These are deprecated now and perhaps
since the types are private so they couldn't be used, we can gte away with a
purely technical semver violation and just remove them? I'm not sure.
> API visibility issues: Internal types are exposed in public API
> ---
>
> Key: LANG-1653
> URL: https://issues.apache.org/jira/browse/LANG-1653
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.12.0
>Reporter: Marcono1234
>Priority: Minor
>
> There are a few cases where public classes expose internal {{private}} types.
> These internal types prevent usage of the methods or fields exposing them.
> Affected:
> - {{org.apache.commons.lang3.ThreadUtils}}: Exposes private type
> {{AlwaysTruePredicate}} through field
> [{{ALWAYS_TRUE_PREDICATE}}|https://github.com/apache/commons-lang/blob/d1e9e598c9bcbf91afa174fa9b6c2ef30bbc8157/src/main/java/org/apache/commons/lang3/ThreadUtils.java#L148]
> The field should probably instead have the type {{ThreadPredicate}}.
> - {{org.apache.commons.lang3.time.FastDatePrinter}}: The following protected
> methods expose private types:
> --
> [{{selectNumberRule}}|https://github.com/apache/commons-lang/blob/d1e9e598c9bcbf91afa174fa9b6c2ef30bbc8157/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java#L385]:
> Exposes private {{NumberRule}}
> --
> [{{parsePattern}}|https://github.com/apache/commons-lang/blob/d1e9e598c9bcbf91afa174fa9b6c2ef30bbc8157/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java#L185]:
> Exposes private {{Rule}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1634) ObjectUtils - apply Consumer with non-null value
[
https://issues.apache.org/jira/browse/LANG-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816435#comment-17816435
]
Elliotte Rusty Harold commented on LANG-1634:
-
Dupe of LANG-1633. Close this one
> ObjectUtils - apply Consumer with non-null value
>
>
> Key: LANG-1634
> URL: https://issues.apache.org/jira/browse/LANG-1634
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Bindul Bhowmik
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> There are multiple places in code where we have to check if a value is
> {{null}} before using it in a setter or other method, like:
> {code:java}
> if (valueX != null) {
> bean.setValue(valueX);
> someObject.compute(valueX, "bar");
> }
> {code}
> This enhancement request is to add a couple of methods in {{ObjectUtils}} to
> wrap this logic, like the following:
> {code:java}
> public static void applyIfNonNull(final Consumer consumer, final T
> object)
> public static void applyFirstNonNull(final Consumer consumer, final
> T... objects)
> {code}
> With this the two statements above could be used as:
> {code:java}
> ObjectUtils.applyIfNonNull(bean::setValue, valueX);
> ObjectUtils.appyIfNonNull(v -> someObject.compute(v, "bar"), valueX);
> {code}
> The benefit of this should increase with more such null checks we need in the
> code that can be replaced by single statements.
> Pull request forthcoming.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1599) Creating a Kotlin Commons Lang package.
[ https://issues.apache.org/jira/browse/LANG-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816434#comment-17816434 ] Elliotte Rusty Harold commented on LANG-1599: - I agree. If Kotlin folks want and are willing to support this, it will work much better as a new, independent project. I propose won't fixing the issue for commons lang. > Creating a Kotlin Commons Lang package. > --- > > Key: LANG-1599 > URL: https://issues.apache.org/jira/browse/LANG-1599 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Adwait Kumar Singh >Priority: Minor > > Kotlin introduced the concept of Extension functions which are more concise > than regular functions and allow easy discoverability. > There was a proposal earlier https://issues.apache.org/jira/browse/LANG-1538 > in which it was suggested to create a different project all together. > Opening this issue to discuss if we want to create this package and what > would it take to get this through. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-607) StringUtils methods do not handle Unicode 2.0+ supplementary characters correctly.
[ https://issues.apache.org/jira/browse/LANG-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816432#comment-17816432 ] Elliotte Rusty Harold commented on LANG-607: ping, should be closed per comment > StringUtils methods do not handle Unicode 2.0+ supplementary characters > correctly. > -- > > Key: LANG-607 > URL: https://issues.apache.org/jira/browse/LANG-607 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.5 > Environment: java version "1.6.0_16" > Java(TM) SE Runtime Environment (build 1.6.0_16-b01) > Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) > Microsoft Windows [Version 6.0.6002] > Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_16 > Java home: C:\Program Files\Java\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows" >Reporter: Gary Gregory >Assignee: Gary D. Gregory >Priority: Minor > Fix For: Patch Needed > > Attachments: LANG-607.diff > > > StringUtils.containsAny methods incorrectly matches Unicode 2.0+ > supplementary characters. > For example, define a test fixture to be the Unicode character U+2 where > U+2 is written in Java source as "\uD840\uDC00" > private static final String CharU2 = "\uD840\uDC00"; > private static final String CharU20001 = "\uD840\uDC01"; > You can see Unicode supplementary characters correctly implemented in the JRE > call: > assertEquals(-1, CharU2.indexOf(CharU20001)); > But this is broken: > assertEquals(false, StringUtils.containsAny(CharU2, CharU20001)); > assertEquals(false, StringUtils.containsAny(CharU20001, CharU2)); > This is fine: > assertEquals(true, StringUtils.contains(CharU2 + CharU20001, > CharU2)); > assertEquals(true, StringUtils.contains(CharU2 + CharU20001, > CharU20001)); > assertEquals(true, StringUtils.contains(CharU2, CharU2)); > assertEquals(false, StringUtils.contains(CharU2, CharU20001)); > because the method calls the JRE to perform the match. > More than you want to know: > - http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-923) JDK 1.8 Changes
[ https://issues.apache.org/jira/browse/LANG-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816423#comment-17816423 ] Elliotte Rusty Harold commented on LANG-923: probably time to close this one > JDK 1.8 Changes > --- > > Key: LANG-923 > URL: https://issues.apache.org/jira/browse/LANG-923 > Project: Commons Lang > Issue Type: Task > Components: General >Reporter: Henri Yandell >Priority: Major > Fix For: 4.0 > > > Omnibus issue to cover any JDK 1.8 related changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1531) escapeXml10 does not escape newline and tab characters to #xA
[ https://issues.apache.org/jira/browse/LANG-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816422#comment-17816422 ] Elliotte Rusty Harold commented on LANG-1531: - This is a misreading of the XML spec. There's no reason to change the method. It is correct as written, and this bug should be closed. > escapeXml10 does not escape newline and tab characters to #xA > - > > Key: LANG-1531 > URL: https://issues.apache.org/jira/browse/LANG-1531 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.8.1, 3.10 >Reporter: devson >Priority: Major > > escapexml10 in StringEscapeUtils does not escape newline(line feed) and tab > characters to #xA but it should escape them as specified in > [https://www.w3.org/TR/xml/#sec-line-ends] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (LANG-1531) escapeXml10 does not escape newline and tab characters to #xA
[ https://issues.apache.org/jira/browse/LANG-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816421#comment-17816421 ] Elliotte Rusty Harold edited comment on LANG-1531 at 2/11/24 2:11 PM: -- I disagree. If the class still exists AND it has a bug and we're shipping it, then the bug should be fixed, even in a deprecated method. I'm not sure this is a bug though. Need to investigate further. was (Author: elharo): I disagree. I the class still exists AND it has a bug and we're shipping it, then the bug should be fixed, even in a deprecated method. I'm not sure this is a bug though. Need to investigate further. > escapeXml10 does not escape newline and tab characters to #xA > - > > Key: LANG-1531 > URL: https://issues.apache.org/jira/browse/LANG-1531 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.8.1, 3.10 >Reporter: devson >Priority: Major > > escapexml10 in StringEscapeUtils does not escape newline(line feed) and tab > characters to #xA but it should escape them as specified in > [https://www.w3.org/TR/xml/#sec-line-ends] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (LANG-1531) escapeXml10 does not escape newline and tab characters to #xA
[ https://issues.apache.org/jira/browse/LANG-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816421#comment-17816421 ] Elliotte Rusty Harold edited comment on LANG-1531 at 2/11/24 2:10 PM: -- I disagree. I the class still exists AND it has a bug and we're shipping it, then the bug should be fixed, even in a deprecated method. I'm not sure this is a bug though. Need to investigate further. was (Author: elharo): I disagree if the class still exists and it has a bug and we're shipping it, then the bug should be fixed, even in a deprecated method. I'm not sure this is a bug though. Need to investigate further. > escapeXml10 does not escape newline and tab characters to #xA > - > > Key: LANG-1531 > URL: https://issues.apache.org/jira/browse/LANG-1531 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.8.1, 3.10 >Reporter: devson >Priority: Major > > escapexml10 in StringEscapeUtils does not escape newline(line feed) and tab > characters to #xA but it should escape them as specified in > [https://www.w3.org/TR/xml/#sec-line-ends] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1531) escapeXml10 does not escape newline and tab characters to #xA
[ https://issues.apache.org/jira/browse/LANG-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816421#comment-17816421 ] Elliotte Rusty Harold commented on LANG-1531: - I disagree if the class still exists and it has a bug and we're shipping it, then the bug should be fixed, even in a deprecated method. I'm not sure this is a bug though. Need to investigate further. > escapeXml10 does not escape newline and tab characters to #xA > - > > Key: LANG-1531 > URL: https://issues.apache.org/jira/browse/LANG-1531 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.8.1, 3.10 >Reporter: devson >Priority: Major > > escapexml10 in StringEscapeUtils does not escape newline(line feed) and tab > characters to #xA but it should escape them as specified in > [https://www.w3.org/TR/xml/#sec-line-ends] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1650) Release notes link is broken
[ https://issues.apache.org/jira/browse/LANG-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816420#comment-17816420 ] Elliotte Rusty Harold commented on LANG-1650: - I think this one is moot given other changes on that page. I don't see the broken link any more. Please close. > Release notes link is broken > > > Key: LANG-1650 > URL: https://issues.apache.org/jira/browse/LANG-1650 > Project: Commons Lang > Issue Type: Bug > Components: General >Affects Versions: 3.12.0 >Reporter: Václav Haisman >Priority: Major > Labels: documentation > > The link to "relase notes" on the module page at > [https://commons.apache.org/proper/commons-lang/] is broken. It points at > [https://commons.apache.org/proper/commons-lang/release-notes/RELEASE-NOTES-3.12.txt] > but such file does not exist. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1414) commons.componentId is incorrectly set to lang3
[ https://issues.apache.org/jira/browse/LANG-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816419#comment-17816419 ] Elliotte Rusty Harold commented on LANG-1414: - This is what I see today in pom.xml: lang This seems to have been fixed at some point and can be closed. > commons.componentId is incorrectly set to lang3 > --- > > Key: LANG-1414 > URL: https://issues.apache.org/jira/browse/LANG-1414 > Project: Commons Lang > Issue Type: Bug > Components: General >Reporter: Benedikt Ritter >Priority: Major > Fix For: 3.15.0 > > > It looks like the property commons.componentId should be set to lang and not > to lang3. See > [https://lists.apache.org/thread.html/304129bf7d25a2118ee3f324214c04e1e8f0846e7ee43a57b100a26e@%3Cdev.commons.apache.org%3E] > We need to find out whether this breaks something and then change the > componentId. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-143) Update dependency on avalon-framework
[ https://issues.apache.org/jira/browse/LOGGING-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816414#comment-17816414 ] Elliotte Rusty Harold commented on LOGGING-143: --- Avalon is dead, and we should remove it here. Close this one as won't do. > Update dependency on avalon-framework > - > > Key: LOGGING-143 > URL: https://issues.apache.org/jira/browse/LOGGING-143 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Stanislav Ochotnicky >Priority: Minor > Labels: build, patch > Fix For: 2.0 > > Attachments: commons-logging-avalon-update.patch > > > Commons logging currently uses avalon-framework 4.1.3 while 4.3 exists and > provides a nice split between api and implementation. Attached is a patch > updating dependency to new version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-95) Extended API: getChildLogger(String)
[ https://issues.apache.org/jira/browse/LOGGING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816412#comment-17816412 ] Elliotte Rusty Harold commented on LOGGING-95: -- probably close as won't do if we're now nudging people to other logging frameworks. > Extended API: getChildLogger(String) > > > Key: LOGGING-95 > URL: https://issues.apache.org/jira/browse/LOGGING-95 > Project: Commons Logging > Issue Type: Improvement > Environment: Operating System: other > Platform: Other >Reporter: Jörg Hohwiller >Priority: Minor > Fix For: 2.0 > > Attachments: ASF.LICENSE.NOT.GRANTED--Logger.java, > ASF.LICENSE.NOT.GRANTED--getChildLogger.diff > > > This is a feature request for the commons-logging API already discussed on > the mailing list. The idea is to have an extended interface rather than Log > that adds additional methods (getChildLogger and getName) that have already > been requested for a long while. The suggested approach does not break > compatibility of JCL. The existing Log interface is not touched and shall > esp. not be deprecated. The new interface may only be used as needed but aims > to prevent having even more additional logging APIs in future. The suggestion > is to change the implementation in a way that all classes that implement Log > shall implement Logger and fullfill the contract of the additional methods. > In my request I still leave it open what happens to LogFactory but my > suggestion is to leave it untouched (except for javadoc updates). Further I > recomment to add an abstract class to the "impl" package that implements the > Logger interface but does not implement any methods. The Logger interface may > then recommend in its javadoc to extend the abstract class rather than > directly implementing the interface. This would allow to have less trouble if > -however- in future an additional feature request for the Logger API arises. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-166) Log4J2 Wrapper Class
[ https://issues.apache.org/jira/browse/LOGGING-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816411#comment-17816411 ] Elliotte Rusty Harold commented on LOGGING-166: --- There are no tests. You can send patches as PRs on github, but they need tests. > Log4J2 Wrapper Class > > > Key: LOGGING-166 > URL: https://issues.apache.org/jira/browse/LOGGING-166 > Project: Commons Logging > Issue Type: New Feature >Reporter: Igor Kriznar >Priority: Minor > Attachments: Log4J2Logger.java > > > Hi, I am contributing wrapper for Log4J 2. Works for me. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-184) Logging DOAP file has an error
[
https://issues.apache.org/jira/browse/LOGGING-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816410#comment-17816410
]
Elliotte Rusty Harold commented on LOGGING-184:
---
wrong project. This is in log4cxx. Please report there. This issue can be
closed as invalid.
> Logging DOAP file has an error
> --
>
> Key: LOGGING-184
> URL: https://issues.apache.org/jira/browse/LOGGING-184
> Project: Commons Logging
> Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Claude Warren
>Priority: Minor
>
> The DOAP file [1] as listed in [2] has the error:
> [line: 26, col: 4 ] \{E201} The attributes on this property element, are not
> permitted with any content; expecting end element tag.
> [1]
> https://gitbox.apache.org/repos/asf?p=logging-log4cxx.git;a=blob_plain;f=doap_log4cxx.rdf;hb=HEAD
> [2]
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOGGING-179) Redundant type cast and boxing
[ https://issues.apache.org/jira/browse/LOGGING-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816409#comment-17816409 ] Elliotte Rusty Harold commented on LOGGING-179: --- This was done and can be closed. > Redundant type cast and boxing > -- > > Key: LOGGING-179 > URL: https://issues.apache.org/jira/browse/LOGGING-179 > Project: Commons Logging > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-152) Helper class that redirects OutputStream to Log
[
https://issues.apache.org/jira/browse/LOGGING-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816406#comment-17816406
]
Elliotte Rusty Harold commented on LOGGING-152:
---
Feels like the wrong place to put this. It's not how logs usually work. Plus
it's unclear if we want to add any new features to commons-logging rather than
nudging users onto other frameworks. I suggest closing as won't do.
> Helper class that redirects OutputStream to Log
> ---
>
> Key: LOGGING-152
> URL: https://issues.apache.org/jira/browse/LOGGING-152
> Project: Commons Logging
> Issue Type: Improvement
>Affects Versions: 1.1.1
>Reporter: Dmitry Katsubo
>Priority: Major
> Attachments: LoggingOutputStream.java
>
>
> Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for
> debug messages to be printed to. The attached class acts as a bridge between
> {{OutputStream}} and {{org.apache.commons.logging.Log}}.
> Example of usage:
> {code}
> PrintStream loggingPrintStream = new PrintStream(new
> LoggingOutputStream(logger, LoggingOutputStream.LogLevel.INFO, "[XJC] "));
> com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
> {code}
> Also has some overlap with LOGGING-110.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOGGING-112) Commons Logging in SLF4J flavour
[ https://issues.apache.org/jira/browse/LOGGING-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816405#comment-17816405 ] Elliotte Rusty Harold commented on LOGGING-112: --- Will probably happen one of these days, but this issue and patch is long out of date and should be closed. > Commons Logging in SLF4J flavour > > > Key: LOGGING-112 > URL: https://issues.apache.org/jira/browse/LOGGING-112 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Systems supporting JRE version 1.3 and above. >Reporter: Boris Unckel >Priority: Major > Fix For: 2.0 > > Attachments: jcl-2.0.0.zip > > > There were some related discussions on the dev mailing list about a possible > JCL 2.0.0. > I have created a first draft version of JCL in SLF4J (http://www.slf4j.org/) > flavour. > It is based on Maven 2 and a clean separation of API and implementations, > without any fallback for an implementation > in runtime. It still consists of the same Log Wrappers as 1.1.x with one jar > each. > The source lacks on documentation and the JUnits are not ported yet. > This code is intended to show that an improved implementation has worth in > discussing and use. > It has been tested with Apache Tomcat 5.5.23 and JDK 6.0 on Windows Vista. > Please send your comments to the mailing list and not in the JIRA. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-136) API Enhancements: 'String.format(String, Object...)' Functionality & Delegate Convenience Methods
[
https://issues.apache.org/jira/browse/LOGGING-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816404#comment-17816404
]
Elliotte Rusty Harold commented on LOGGING-136:
---
sounds like this issue should be closed a won't do.
Deprecation of this library is a separate question. I don't mind recommending
other libraries in preference to this one, but I do think we need to be aware
that this is already deeply embedded in many projects so some level of support
that doesn't require a migration to something else is valuable.
> API Enhancements: 'String.format(String, Object...)' Functionality & Delegate
> Convenience Methods
> -
>
> Key: LOGGING-136
> URL: https://issues.apache.org/jira/browse/LOGGING-136
> Project: Commons Logging
> Issue Type: Improvement
>Affects Versions: 1.1.1
> Environment: N/A
>Reporter: Daniel Siviter
>Priority: Major
> Labels: api, api-addition
> Fix For: 2.0
>
> Attachments: commons-logging-1.1.1-src.rar,
> commons-logging-1.1.1.jar, site.rar
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Improvements to the API to allow convenience methods for performing
> {{String.format(String, Object...)}} and allow access to the internal logging
> delegate.
> Firstly, to add the {{String#format(String, Object...)}} functionality modify
> the methods (note: only {{#trace(...)}} shown):
> {{void trace(Object message, Object... args);}}
> {{void trace(Object message, Throwable t, Object... args);}}
> This would allow compatiblity with previous versions of the API (although I
> believe they would still require a re-compile) and help tidy up code.
> Secondly, to obtain access to the internal instance of a logger the addition
> of a {{#getDeletegate()}} method.
> I can supply the code if required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOGGING-181) Remove log4j1 from commons-logging
[ https://issues.apache.org/jira/browse/LOGGING-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816402#comment-17816402 ] Elliotte Rusty Harold commented on LOGGING-181: --- This can be closed as a dupe of 180 and others, though we really do need to take care of this > Remove log4j1 from commons-logging > -- > > Key: LOGGING-181 > URL: https://issues.apache.org/jira/browse/LOGGING-181 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Tharindu Dharmarathna >Priority: Major > > In current commons-logging dependencies, it packs the log4j1 related > dependencies inside in jar. > Since log4j1 retired in 2015 as per [1], Is there any plan to release a new > commons-logging version, removing the log4j1 related dependencies?. > [1] - [https://logging.apache.org/log4j/1.2/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-175) Change Deprecated API usage
[
https://issues.apache.org/jira/browse/LOGGING-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816401#comment-17816401
]
Elliotte Rusty Harold commented on LOGGING-175:
---
This one seems to be done and can be closed.
> Change Deprecated API usage
> ---
>
> Key: LOGGING-175
> URL: https://issues.apache.org/jira/browse/LOGGING-175
> Project: Commons Logging
> Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Major
>
> Change deprecated File.toURL and use
>
> {code:java}
> new File(filename).toURI().toURL();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOGGING-165) Add Automatic-Module-Name Manifest Header for Java 9 compatibility
[ https://issues.apache.org/jira/browse/LOGGING-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816400#comment-17816400 ] Elliotte Rusty Harold commented on LOGGING-165: --- This one seems to be done and can be closed. > Add Automatic-Module-Name Manifest Header for Java 9 compatibility > -- > > Key: LOGGING-165 > URL: https://issues.apache.org/jira/browse/LOGGING-165 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: 陈宝仪 >Priority: Major > Fix For: 1.3.1 > > > Ading modularity headers so that other module can import it > [My project|https://github.com/leonchen83/redis-replicator] using > commons-logging as dependency. > When I use maven build my project. shows following warning: > [INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ > redis-replicator --- > [WARNING] > > [WARNING] * Required filename-based automodules detected. Please don't > publish this project to a public artifact repository! * > [WARNING] > > The root cause is commons-logging-1.2 is not a standard java 9 module(miss > module-info.java). > Env: > java version "9" > Java(TM) SE Runtime Environment (build 9+181) > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-51) Throttled input and output stream classes
[ https://issues.apache.org/jira/browse/IO-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816299#comment-17816299 ] Elliotte Rusty Harold commented on IO-51: - This should be resoloved. > Throttled input and output stream classes > - > > Key: IO-51 > URL: https://issues.apache.org/jira/browse/IO-51 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers > Environment: Operating System: other > Platform: All >Reporter: Gareth Davis >Assignee: Gary D. Gregory >Priority: Minor > Attachments: ASF.LICENSE.NOT.GRANTED--throttle-example.jar, > ASF.LICENSE.NOT.GRANTED--throttle-source.jar, > ASF.LICENSE.NOT.GRANTED--throttle-source.jar > > > Additional classes for the commons-io package. > Three new classes, the new test classes and one example class. > io.Limiter - Core class shared between the input and output streams that > provides the central functions > for the throttle io streams > io.input.ThrottledInputStream - Input Stream implementation > io.output.ThrottledOutputStream - Output Stream implementation > Gareth -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-420) Detection of deleted directories fails if the directory does not exist when the observer is created.
[ https://issues.apache.org/jira/browse/IO-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816298#comment-17816298 ] Elliotte Rusty Harold commented on IO-420: -- Looks like I don't get a created event either in this case > Detection of deleted directories fails if the directory does not exist when > the observer is created. > > > Key: IO-420 > URL: https://issues.apache.org/jira/browse/IO-420 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.4 >Reporter: Joerg Pacher >Priority: Major > > If a directory is observed, that doesn't exist when the observer is created, > no deletion event will be created, when this directory is deleted again. > Use case: mounting/unmounting of usb devices -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-387) IOUtils method to copy File Streams using NIO Channels
[ https://issues.apache.org/jira/browse/IO-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816296#comment-17816296 ] Elliotte Rusty Harold commented on IO-387: -- I like the auto-switch idea, especially if performance improvements can be measured. Do we have benchmarks for this? A new method doesn't seem needed, especially since any performance improvements might not hold in future JDKs. > IOUtils method to copy File Streams using NIO Channels > -- > > Key: IO-387 > URL: https://issues.apache.org/jira/browse/IO-387 > Project: Commons IO > Issue Type: New Feature >Reporter: Sebb >Priority: Major > > Might be useful to have a method to copy FileStreams using NIO channels. > This should generally be faster than using byte buffers (and may use less > memory). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-420) Detection of deleted directories fails if the directory does not exist when the observer is created.
[ https://issues.apache.org/jira/browse/IO-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816295#comment-17816295 ] Elliotte Rusty Harold commented on IO-420: -- To expand, is this the current behavior? 1. Observe a directory 2. Directory is created 3. Directory created event is fired 4. Directory is deleted 5. No event is fired > Detection of deleted directories fails if the directory does not exist when > the observer is created. > > > Key: IO-420 > URL: https://issues.apache.org/jira/browse/IO-420 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.4 >Reporter: Joerg Pacher >Priority: Major > > If a directory is observed, that doesn't exist when the observer is created, > no deletion event will be created, when this directory is deleted again. > Use case: mounting/unmounting of usb devices -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IO-405) Support threshold=0 in ThresholdingOutputStream
[ https://issues.apache.org/jira/browse/IO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816294#comment-17816294 ] Elliotte Rusty Harold edited comment on IO-405 at 2/10/24 10:57 AM: This is fixed now and can be resolved. was (Author: elharo): This is fixed now and can be resolve. > Support threshold=0 in ThresholdingOutputStream > --- > > Key: IO-405 > URL: https://issues.apache.org/jira/browse/IO-405 > Project: Commons IO > Issue Type: Improvement > Components: Streams/Writers >Affects Versions: 2.5 >Reporter: Jochen Wiedmann >Assignee: Jochen Wiedmann >Priority: Minor > > I recently had a case where I would wish threshold=0 to trigger an immediate > thresholdReached() in ThresholdingOutputStream(). This seems to me to be a > natural expectation. However, thresholdReached() is only triggered after the > first byte has been written. > I'd like to modify the constructor of ThresholdingOutputStream() in that > sense. However, as thresholdReached() might throw an IOException, there are > two possibilities I'd like to discuss: > 1.) Pass the IOException through. Or, in other words: Modify the constructor > to throw an IOException. (Slight binary incompatibility.) > 2.) Catch the IOException, pass on a RuntimeException. Source code > compatibility, but surprising for the developer. > Personally, I'm in favour for 1.) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IO-405) Support threshold=0 in ThresholdingOutputStream
[ https://issues.apache.org/jira/browse/IO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800172#comment-17800172 ] Elliotte Rusty Harold edited comment on IO-405 at 2/10/24 10:56 AM: I don't see any reason for the constructor to fire the event. Looking at the code I do notice that it doesn't really document or test what happens when the threshold is less than one, though I think the first byte written probably does fire the event. I'll need to add a test for that. was (Author: elharo): I don't see any reason for the constructor to throw an exception. Looking at the code I do notice that it doesn't really document or test what happens when the threshold is less than one, though I think the first byte written probably does throw an exception. I'll need to add a test for that. > Support threshold=0 in ThresholdingOutputStream > --- > > Key: IO-405 > URL: https://issues.apache.org/jira/browse/IO-405 > Project: Commons IO > Issue Type: Improvement > Components: Streams/Writers >Affects Versions: 2.5 >Reporter: Jochen Wiedmann >Assignee: Jochen Wiedmann >Priority: Minor > > I recently had a case where I would wish threshold=0 to trigger an immediate > thresholdReached() in ThresholdingOutputStream(). This seems to me to be a > natural expectation. However, thresholdReached() is only triggered after the > first byte has been written. > I'd like to modify the constructor of ThresholdingOutputStream() in that > sense. However, as thresholdReached() might throw an IOException, there are > two possibilities I'd like to discuss: > 1.) Pass the IOException through. Or, in other words: Modify the constructor > to throw an IOException. (Slight binary incompatibility.) > 2.) Catch the IOException, pass on a RuntimeException. Source code > compatibility, but surprising for the developer. > Personally, I'm in favour for 1.) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-405) Support threshold=0 in ThresholdingOutputStream
[ https://issues.apache.org/jira/browse/IO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816294#comment-17816294 ] Elliotte Rusty Harold commented on IO-405: -- This is fixed now and can be resolve. > Support threshold=0 in ThresholdingOutputStream > --- > > Key: IO-405 > URL: https://issues.apache.org/jira/browse/IO-405 > Project: Commons IO > Issue Type: Improvement > Components: Streams/Writers >Affects Versions: 2.5 >Reporter: Jochen Wiedmann >Assignee: Jochen Wiedmann >Priority: Minor > > I recently had a case where I would wish threshold=0 to trigger an immediate > thresholdReached() in ThresholdingOutputStream(). This seems to me to be a > natural expectation. However, thresholdReached() is only triggered after the > first byte has been written. > I'd like to modify the constructor of ThresholdingOutputStream() in that > sense. However, as thresholdReached() might throw an IOException, there are > two possibilities I'd like to discuss: > 1.) Pass the IOException through. Or, in other words: Modify the constructor > to throw an IOException. (Slight binary incompatibility.) > 2.) Catch the IOException, pass on a RuntimeException. Source code > compatibility, but surprising for the developer. > Personally, I'm in favour for 1.) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IO-847) Deprecate public static boolean contentEqualsIgnoreEOL(final File file1, final File file2, final String charsetName)
[ https://issues.apache.org/jira/browse/IO-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed IO-847. > Deprecate public static boolean contentEqualsIgnoreEOL(final File file1, > final File file2, final String charsetName) > > > Key: IO-847 > URL: https://issues.apache.org/jira/browse/IO-847 > Project: Commons IO > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Minor > > Files can be compared byte per byte and we have a method to do that. I can't > see a reason to convert two files to the same character set and then compare > them. This gives the same answer in all cases where the character encoding is > recognized. If the character set isn't available, it might or mght not fail > in a new but unhelpful way. > Arguably there is a use case for comparing two files with two different > character sets, but that's not what this method does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IO-847) Deprecate public static boolean contentEqualsIgnoreEOL(final File file1, final File file2, final String charsetName)
[ https://issues.apache.org/jira/browse/IO-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved IO-847. -- Resolution: Not A Problem NVM, the charset is needed for the EOL characters > Deprecate public static boolean contentEqualsIgnoreEOL(final File file1, > final File file2, final String charsetName) > > > Key: IO-847 > URL: https://issues.apache.org/jira/browse/IO-847 > Project: Commons IO > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Minor > > Files can be compared byte per byte and we have a method to do that. I can't > see a reason to convert two files to the same character set and then compare > them. This gives the same answer in all cases where the character encoding is > recognized. If the character set isn't available, it might or mght not fail > in a new but unhelpful way. > Arguably there is a use case for comparing two files with two different > character sets, but that's not what this method does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-847) Deprecate public static boolean contentEqualsIgnoreEOL(final File file1, final File file2, final String charsetName)
Elliotte Rusty Harold created IO-847: Summary: Deprecate public static boolean contentEqualsIgnoreEOL(final File file1, final File file2, final String charsetName) Key: IO-847 URL: https://issues.apache.org/jira/browse/IO-847 Project: Commons IO Issue Type: Improvement Reporter: Elliotte Rusty Harold Files can be compared byte per byte and we have a method to do that. I can't see a reason to convert two files to the same character set and then compare them. This gives the same answer in all cases where the character encoding is recognized. If the character set isn't available, it might or mght not fail in a new but unhelpful way. Arguably there is a use case for comparing two files with two different character sets, but that's not what this method does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CODEC-263) Base64.decodeBase64 throw exception
[
https://issues.apache.org/jira/browse/CODEC-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814347#comment-17814347
]
Elliotte Rusty Harold commented on CODEC-263:
-
Near as I can tell this issue doesn't reproduce and can be closed.
> Base64.decodeBase64 throw exception
> ---
>
> Key: CODEC-263
> URL: https://issues.apache.org/jira/browse/CODEC-263
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.13
> Environment: JDK 7/JDK 8
> commons-codec 1.13
>Reporter: xie tao
>Priority: Critical
> Attachments: image-jpg-01-big.base64.txt
>
>
> Codec upgrade to 1.13, code throw exception as follows：
> {code:java}
> @Test
> public void test(){
> Base64.decodeBase64("publishMessage");
> }
> {code}
> exception like：
> {code:java}
> java.lang.IllegalArgumentException: Last encoded character (before the
> paddings if any) is a valid base 64 alphabet but not a possible value
> at
> org.apache.commons.codec.binary.Base64.validateCharacter(Base64.java:798)
> at org.apache.commons.codec.binary.Base64.decode(Base64.java:472)
> at
> org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:412)
> at
> org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:395)
> at org.apache.commons.codec.binary.Base64.decodeBase64(Base64.java:694)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-199) Replace strings in file
[
https://issues.apache.org/jira/browse/IO-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814094#comment-17814094
]
Elliotte Rusty Harold commented on IO-199:
--
Also IO-218 is covering some of the same ground.
> Replace strings in file
> ---
>
> Key: IO-199
> URL: https://issues.apache.org/jira/browse/IO-199
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Alexander Stroell
>Priority: Minor
> Fix For: 3.x
>
>
> A method, that can replace strings (keys) in a file would be very useful.
> For example if you have a file with the following text:
> {noformat}
> The packet must arrive between @dateFrom and @dateTo.
> {noformat}
> You can now replace the "keys" with a value of your choice..
> Perhaps something like this:
> {code}
> public static void replaceStrings(File inputFile, File outputFile,
> List> replacements) throws IOException{
> BufferedReader in = new BufferedReader(new
> FileReader(inputFile));
> BufferedWriter out = new BufferedWriter(new
> FileWriter(outputFile));
>
> String line;
>
> while ((line = in.readLine()) != null) {
> for(KeyValuePair kvp : replacements){
> line = line.replace(kvp.getKey(),
> kvp.getValue());
> }
> out.write(line);
> out.newLine();
> }
> out.flush();
> out.close();
> in.close();
> }
> {code}
> I think it should also be possible, to replace the strings in the inputfile
> so you don't have to create a new file (outputfile)
> Regards Alex
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-384) New FileUtils method to copy file which might change in size
[ https://issues.apache.org/jira/browse/IO-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814090#comment-17814090 ] Elliotte Rusty Harold commented on IO-384: -- This issue is probably obsolete. FileUtils.copyFile now uses the Files.copy method in the JDK. doCopyFile and the implementation described here no longer exist. > New FileUtils method to copy file which might change in size > > > Key: IO-384 > URL: https://issues.apache.org/jira/browse/IO-384 > Project: Commons IO > Issue Type: New Feature >Reporter: Sebb >Priority: Major > > As mentioned in IO-383, FileUtils.doCopyFile caches the file size. > This means that a growing file (e.g. a log file) may cause the method to > report failure. > It might be useful to have a method which keeps looping until there is no > more input; this should not throw an IOE if the sizes are different. > More data may have been added - or the file truncated - between completing > the copy and checking the size. > The method should return the total bytes written; the caller can then check > if the count is OK. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-364) Allow DirectoryWalker provide relative paths in handle*()
[
https://issues.apache.org/jira/browse/IO-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814086#comment-17814086
]
Elliotte Rusty Harold commented on IO-364:
--
I did something like this while working on copyDirectory. This would have some
problems. I think we'd need to pass a root file path down through the various
walk/handle methods so it would be new API. Also, with Java 8+ and
Paths.relativize in the JDK it's no longer hard to subtract one path from
another, so I recommend closing this one as Won't Do.
> Allow DirectoryWalker provide relative paths in handle*()
> -
>
> Key: IO-364
> URL: https://issues.apache.org/jira/browse/IO-364
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.4
>Reporter: Ondra Žižka
>Priority: Major
>
> {code}
> handleFile( File file, int depth, Collection results )
> {code}
> and other methods provide a file object with full path.
> As it's much easier to concat base path and additional path than
> "substracting" one path from other, I suggest:
> The `File` object provided by `handleFile()` and other `handle*` methods
> should (optionally) contain path relative to the one passed to `walk()`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
[ https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814081#comment-17814081 ] Elliotte Rusty Harold commented on IO-845: -- It would be helpful if @eamonnmcmanus could chime in on this. I'm no longer inside the plex, and can't test what they're actually doing. Ultimately this depends on whether the linked resource files copybara is copying during tests are inside the directory being copied or outside of it. I don't know. If they're inside it, then this will fix their issue. If they're outside of it they won't. That said, Google has been relying on undocumented, unintended and frankly surprising behavior of the old version of this method. Until IO-807 I don't think anyone had much thought about or tested how the copyDirectory methods handled symbolic links. Now that I have thought about it, I can't see the previous behavior as sensible. Copying 10 links to the same file 1 MB file should not make 10 MB worth of new files, which is what we were doing. And it's also true that the old behavior had some obvious cycle bugs that are now fixed by copying links as links. We could add a flag to this method somehow that does revert to the old behavior. However it strikes me that actualizing links (i.e. replacing a link with the bytes it links to) should be a separate operation from copying a directory. It might be worth adding a FileUtils.actualize() method that does this. It makes me a little nervous because it's not an atomic operation and could fail halfway through, leaving things in an inconsistent state, but that's true of most I/O methods. > Copying symbolic links. how should FileUtils.copyDirectory. behave? > --- > > Key: IO-845 > URL: https://issues.apache.org/jira/browse/IO-845 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > The current 2.15.1 release and earlier versions have bugs in the copying of > symbolic link cycles using FileUtils.copyDirectory. There are also bugs in > copying broken symbolic links reported in IO-807. These are fixed at head > because symbolic links to directories are now copied as symbolic links rather > than by resolving the files. However this causes problems for some > non-hypothetical existing code that relied on the old behavior for copying > directories containing non-cyclical symbolic links.In particular, Google has > [reported failures in some of their internal > projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] > when using the version at head as a result of this. However I don't think > that the directories Google is copying contain cycles, so they weren't > hitting the old bugs. > The question is how to resolve this so that FileUtils.copyDirectory behaves > reasonably with all possible directories whether cycles are present or not. > Is there a consistent and reasonable way we can or should copy some links to > directories as directories and others as actual directories? There are a > number of cases to consider: > 1. No symbolic links. Just copy everything and we're good. > 2. Symbolic links but only to files, not directories. Copy the file or copy > the link? > 3. Symbolic links but only to files within the root directory being copied. > Right now at head we create a link to the old directory in the source. We > could instead create a link to the new directory in the target. > 4. Symbolic links to files outside the root directory being copied. Right now > at head we create a link to the old directory in the source. We should > probably keep this behavior. > I think the behavior we want is as follows, and then I think we handle most > use cases while avoiding cycle problems: > 1. Start from a root directory, the source. > 2. Never copy anything that is not contained in that directory to the target. > 3. When walking the directory tree, if a symbolic link is encountered: > 3.1 If the symbolic link points outside the source, create a new symbolic > link to the same target. > 3.2 If the symbolic link points to a target inside the source, create a new > symbolic link to the copy of the target. > However every symbolic link in the source turns into a symbolic link in the > copy. Cycles do not cause problems because they are not followed. The only > discrepancy I see in this approach is that a link to a directory outside the > source that is a link that points back into the source still points back into > the source, not the target. Thus the copy can point back into the source > indirectly. Perhaps when copying links that point outside the source we can > fully resolve them to and repoint as needed. > I don't know that this actually fixes Google's problem.
[jira] [Comment Edited] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
[ https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814081#comment-17814081 ] Elliotte Rusty Harold edited comment on IO-845 at 2/4/24 1:26 PM: -- It would be helpful if @eamonnmcmanus could chime in on this. I'm no longer inside the plex, and can't test what they're actually doing. Ultimately this depends on whether the linked resource files copybara is copying during tests are inside the directory being copied or outside of it. I don't know. If they're inside it, then this will fix their issue. If they're outside of it they won't. That said, Google has been relying on undocumented, unintended, and frankly surprising behavior of the old version of this method. Until IO-807 I don't think anyone had much thought about or tested how the copyDirectory methods handled symbolic links. Now that I have thought about it, I can't see the previous behavior as sensible. Copying 10 links to the same 1 MB file should not make 10 MB worth of new files, which is what we were doing. And it's also true that the old behavior had some obvious cycle bugs that are now fixed by copying links as links. We could add a flag to this method somehow that does revert to the old behavior. However it strikes me that actualizing links (i.e. replacing a link with the bytes it links to) should be a separate operation from copying a directory. It might be worth adding a FileUtils.actualize() method that does this. It makes me a little nervous because it's not an atomic operation and could fail halfway through, leaving things in an inconsistent state, but that's true of most I/O methods. was (Author: elharo): It would be helpful if @eamonnmcmanus could chime in on this. I'm no longer inside the plex, and can't test what they're actually doing. Ultimately this depends on whether the linked resource files copybara is copying during tests are inside the directory being copied or outside of it. I don't know. If they're inside it, then this will fix their issue. If they're outside of it they won't. That said, Google has been relying on undocumented, unintended and frankly surprising behavior of the old version of this method. Until IO-807 I don't think anyone had much thought about or tested how the copyDirectory methods handled symbolic links. Now that I have thought about it, I can't see the previous behavior as sensible. Copying 10 links to the same file 1 MB file should not make 10 MB worth of new files, which is what we were doing. And it's also true that the old behavior had some obvious cycle bugs that are now fixed by copying links as links. We could add a flag to this method somehow that does revert to the old behavior. However it strikes me that actualizing links (i.e. replacing a link with the bytes it links to) should be a separate operation from copying a directory. It might be worth adding a FileUtils.actualize() method that does this. It makes me a little nervous because it's not an atomic operation and could fail halfway through, leaving things in an inconsistent state, but that's true of most I/O methods. > Copying symbolic links. how should FileUtils.copyDirectory. behave? > --- > > Key: IO-845 > URL: https://issues.apache.org/jira/browse/IO-845 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > The current 2.15.1 release and earlier versions have bugs in the copying of > symbolic link cycles using FileUtils.copyDirectory. There are also bugs in > copying broken symbolic links reported in IO-807. These are fixed at head > because symbolic links to directories are now copied as symbolic links rather > than by resolving the files. However this causes problems for some > non-hypothetical existing code that relied on the old behavior for copying > directories containing non-cyclical symbolic links.In particular, Google has > [reported failures in some of their internal > projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] > when using the version at head as a result of this. However I don't think > that the directories Google is copying contain cycles, so they weren't > hitting the old bugs. > The question is how to resolve this so that FileUtils.copyDirectory behaves > reasonably with all possible directories whether cycles are present or not. > Is there a consistent and reasonable way we can or should copy some links to > directories as directories and others as actual directories? There are a > number of cases to consider: > 1. No symbolic links. Just copy everything and we're good. > 2. Symbolic links but only to files, not directories. Copy the file or copy > the link? > 3.
[jira] [Commented] (IO-222) New Functionality: FileCopier object to facilitate copying of files and directories with ability to customize treatment of existing destination files and report copy status
[ https://issues.apache.org/jira/browse/IO-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813948#comment-17813948 ] Elliotte Rusty Harold commented on IO-222: -- This is an interesting idea, and impacts on the APIs I've been thinking about for symbolic links. However, after 15 years and no action it's unlikely we can start with exactly this, and probably duplicates some of the functionality in FileFilters. For now, I;d close this one as Won't Do. > New Functionality: FileCopier object to facilitate copying of files and > directories with ability to customize treatment of existing destination files > and report copy status > > > Key: IO-222 > URL: https://issues.apache.org/jira/browse/IO-222 > Project: Commons IO > Issue Type: New Feature > Components: Utilities > Environment: any >Reporter: David Armstrong >Priority: Minor > Fix For: 3.x > > Attachments: commons-io-1.5-SNAPSHOT-javadocs.tar.gz, > commons-io-1.5-SNAPSHOT.diff, commons-io-1.5-SNAPSHOT.tar.gz > > Original Estimate: 8h > Remaining Estimate: 8h > > This is a proposal to add a feature to new releases of Commons IO. > The new functionality is a class that copies files, called FileCopier and > some helper classes. This class goes beyond the functionality of the static > methods included in the FileUtils class. It has the following functionality: > It uses an extension to an abstract class, FileCopyHelper. FileCopyHelper > provides callback methods to FileCopier's copy methods. Extensions to > FileCopyHelper provide methods to define behavior for handling destination > files that exist, handling exceptions, reporting the status of copy > operations, and enables clients to cancel copies after they have begun. > There are several extensions to FileCopyHelper that I have created. > FileCopyHelper and all of its extensions are included in a new package, > org.apache.commons.io.filecopyhelper to avoid cluttering up > org.apache.commons.io. FileCopier uses a default FileCopyHelper extension, > SafeFileCopyHelper. This extension skips all destination files that already > exist. OverwriteFileCopyHelper overwrites all files that exist. > RenameAppendFileCopyHelper appends text to the names of all files that exist. > RenameAppendTimestampFileCopyHelper appends the existing file's last modified > date to its name. There are a few other FileCopyHelper extensions included, > also. All of the FileCopyHelper extensions that I created print the status of > copy operations and report exceptions to standard out. Any behavior of the > included FileCopyHelper extensions that are not wanted can be avoided by > extending FileCopyHelper with custom implementations. > FileCopyHelper also allows clients to send a cancel request to FileCopier to > cancel subsequent copy operations. FIleCopier will throw a runtime exception, > FileCopyCancelException, when it receives a request to cancel copy operations. > When copying directories, FileCopier gives clients the ability to "flatten" > directories if they so choose. They can flatten by directory level or by > name, using an IOFileFilter. Flattening means the directory itself is not > copied; only its contents are copied. It likewise gives clients the ability > to "merge" directories that exist. They can merge directories by level or by > name, using an IOFileFilter. Merge is applicable when FileCopier is using a > FileCopyHelper object that renames destination files that already exist. If a > directory is to be merged, it means that the directory is not renamed. The > contents of the source directory are merged with the contents of the already > existing destination directory. Destination directories that are not to be > merged are renamed. FileCopier's default behavior is to not merge or flatten > any directories. > FileCopier is immutable and uses an inner Builder class to create instances > of it. > I made a small change to FileUtils.java. I changed the access for > doCopyFile() from private to protected so that FileCopier could make use of > its functionality. > Included is a FileCopierTestCase class and all of its tests pass. > I've attached a gzipped tar file of Commons IO with the changes I made. If > you generate javadocs, it should create them for the classes I introduced. > Hopefully, they will answer any questions about the functionality that I did > not address here. > Also attached is a diff file of the project's source code after I svn added > my source code. > The estimate I put for this effort is 8 hours, just for the time that would > be spent deciding whether or not to implement the new feature and
[jira] [Commented] (IO-473) Add classpath based lookups to FileUtils
[
https://issues.apache.org/jira/browse/IO-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813940#comment-17813940
]
Elliotte Rusty Harold commented on IO-473:
--
I'm not exactly sure what's being proposed here, or whether this crosses the
notability bar. If it does, it might still be more appropriate for something
like Commons-lang's ClasspathUtils. FileUtils should be about operating on
files, not classpaths. Absent a more complete and compelling description of the
functionality, I propose closing this one as Won't Do.
> Add classpath based lookups to FileUtils
>
>
> Key: IO-473
> URL: https://issues.apache.org/jira/browse/IO-473
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 2.4
>Reporter: Amir Gur
>Priority: Trivial
>
> Lacking classpath based lookup methods such as:
> {code:java}
> - Collection listFiles(String[] extensions)
> - Collection listFiles(String extension, String classpathRoot)
> {code}
> Created [pull request 7|https://github.com/apache/commons-io/pull/7].
>
> Q1: does such classpath based lookup already exists elsewhere (that is on
> such a generic apache commons level, not buried in some other huge
> specialized project). If not exists this is neede.
> Q2: does it belong here, or on another Utils class/package?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-184) FileUtils.isAncestor
[
https://issues.apache.org/jira/browse/IO-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813930#comment-17813930
]
Elliotte Rusty Harold commented on IO-184:
--
This is essentially FileUtils.directoryContains, which already exists. Perhaps
it didn't yet exist when this issue was first filed?
In either case, I recommend closing this issue.
> FileUtils.isAncestor
>
>
> Key: IO-184
> URL: https://issues.apache.org/jira/browse/IO-184
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Reporter: Yu Kobayashi
>Priority: Minor
> Fix For: 3.x
>
>
> Please add FileUtils.isAncestor(). Code is following.
> public static boolean isAncestor(File file, File ancestor) {
> File f = file;
> while (f != null) {
> if (f.equals(ancestor)) return true;
> f = f.getParentFile();
> }
> return false;
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-250) Add FileUtils.pathTo(File aFile, File fromAnotherFile)
[
https://issues.apache.org/jira/browse/IO-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813860#comment-17813860
]
Elliotte Rusty Harold commented on IO-250:
--
As of Java 1.7, this functionality is in the JDK as Paths.relativize. I suggest
closing this.
> Add FileUtils.pathTo(File aFile, File fromAnotherFile)
> --
>
> Key: IO-250
> URL: https://issues.apache.org/jira/browse/IO-250
> Project: Commons IO
> Issue Type: New Feature
> Environment: n/a
>Reporter: Jasper Blues
>Priority: Minor
> Fix For: 3.x
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Please consider adding the following method to
> org.apache.commons.io.FileUtils. I've submitted the method, with test cases
> below (rather than create a patch file). As a single method, it should prove
> very simple to integrate.
> The method returns the path to a file, from another file, as described in the
> Javadoc method header below:
> {code}
> /**
> * Returns the path of a aFile relative to another aFile, for example the
> location of a file:
> * resources/language/english/foobar.properties relative to
> * resources/language/japanese/foobar.properties is
> * ../../english/foobar.properties
> *
> * @param aFile the aFile to check relative location
> * @param fromAnotherFile the base location
> * @return the relative location path
> * @throws java.io.IOException on IO error
> */
> public static String pathTo(File aFile, File fromAnotherFile) throws
> IOException {
> LOGGER.debug("Find path to file: " + aFile.toString() + " from file:
> " + fromAnotherFile.toString());
> Stack fileToDirectories = directoriesFor(aFile);
> Stack fileFromDirectories = directoriesFor(fromAnotherFile);
> while (fileToDirectories.peek().equals(fileFromDirectories.peek())) {
> fileToDirectories.pop();
> fileFromDirectories.pop();
> if (fileToDirectories.isEmpty() || fileFromDirectories.isEmpty())
> {
> break;
> }
> }
> StringBuilder pathToCommonParentDirectory = new StringBuilder();
> while (!fileFromDirectories.isEmpty()) {
> pathToCommonParentDirectory.append("../");
> fileFromDirectories.pop();
> }
> StringBuilder pathToFileFromCommonParentDirectory = new
> StringBuilder();
> while (!fileToDirectories.isEmpty()) {
>
> pathToFileFromCommonParentDirectory.append(fileToDirectories.pop().getName());
> if (!fileToDirectories.isEmpty()) {
> pathToFileFromCommonParentDirectory.append("/");
> }
> }
> return pathToCommonParentDirectory.toString() +
> pathToFileFromCommonParentDirectory.toString();
> }
> private static Stack directoriesFor(File file) throws IOException {
> Stack pathElements = new Stack();
> for (File element = file.getCanonicalFile(); element != null; element
> = element.getParentFile()) {
> pathElements.push(element);
> }
> return pathElements;
> }
> {code}
> . . . this is useful for batch processing, web applications, etc.
> Test Cases:
> {code}
> @Test
> public void pathTo() throws IOException {
> //Setup
> File file1 = new File("configs/js/en/a.xml");
> File file2 = new File("configs/js/ja/a.xml");
> Assert.assertNotNull(file1);
> Assert.assertNotNull(file2);
> //Test
> Assert.assertEquals("../../en/a.xml", FileUtils.pathTo(file1, file2));
> }
> @Test
> public void pathTo_windowsStyleOnUnixMachine() throws IOException {
> File file1 = new File("c:/fred/foobar/dude.properties");
> File file2 = new File("c:/data/zz.txt");
> Assert.assertEquals("../../fred/foobar/dude.properties",
> FileUtils.pathTo(file1, file2));
> Assert.assertEquals("../../../data/zz.txt", FileUtils.pathTo(file2,
> file1));
> }
> @Test
> public void pathTo_fromParentDirectory() throws IOException {
> File file1 = new
> File("ui-performance-enhancer/out/test/ui-performance-enhancer/configs/css/imported.xml");
> File file2 = new
> File("ui-performance-enhancer/out/test/ui-performance-enhancer/configs/css");
> Assert.assertEquals("imported.xml", FileUtils.pathTo(file1, file2));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
[ https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated IO-845: - Description: The current 2.15.1 release and earlier versions have bugs in the copying of symbolic link cycles using FileUtils.copyDirectory. There are also bugs in copying broken symbolic links reported in IO-807. These are fixed at head because symbolic links to directories are now copied as symbolic links rather than by resolving the files. However this causes problems for some non-hypothetical existing code that relied on the old behavior for copying directories containing non-cyclical symbolic links.In particular, Google has [reported failures in some of their internal projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] when using the version at head as a result of this. However I don't think that the directories Google is copying contain cycles, so they weren't hitting the old bugs. The question is how to resolve this so that FileUtils.copyDirectory behaves reasonably with all possible directories whether cycles are present or not. Is there a consistent and reasonable way we can or should copy some links to directories as directories and others as actual directories? There are a number of cases to consider: 1. No symbolic links. Just copy everything and we're good. 2. Symbolic links but only to files, not directories. Copy the file or copy the link? 3. Symbolic links but only to files within the root directory being copied. Right now at head we create a link to the old directory in the source. We could instead create a link to the new directory in the target. 4. Symbolic links to files outside the root directory being copied. Right now at head we create a link to the old directory in the source. We should probably keep this behavior. I think the behavior we want is as follows, and then I think we handle most use cases while avoiding cycle problems: 1. Start from a root directory, the source. 2. Never copy anything that is not contained in that directory to the target. 3. When walking the directory tree, if a symbolic link is encountered: 3.1 If the symbolic link points outside the source, create a new symbolic link to the same target. 3.2 If the symbolic link points to a target inside the source, create a new symbolic link to the copy of the target. However every symbolic link in the source turns into a symbolic link in the copy. Cycles do not cause problems because they are not followed. The only discrepancy I see in this approach is that a link to a directory outside the source that is a link that points back into the source still points back into the source, not the target. Thus the copy can point back into the source indirectly. Perhaps when copying links that point outside the source we can fully resolve them to and repoint as needed. I don't know that this actually fixes Google's problem. They sort of want files if not directories to be resolved when copying. Maybe that's a argument. Maybe that's a separate method like FileUtils.actualizeFiles(directory) that walks a file tree and replaces every link to a file with the contents of the target file. was: The current 2.15.1 release and earlier versions have bugs in the copying of symbolic link cycles using FileUtils.copyDirectory. There are also bugs in copying broken symbolic links reported in IO-807. These are fixed at head because symbolic links to directories are now copied as symbolic links rather than by resolving the files. However this causes problems for some non-hypothetical existing code that relied on the old behavior for copying directories containing non-cyclical symbolic links.In particular, Google has [reported failures in some of their internal projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] when using the version at head as a result of this. However I don't think that the directories Google is copying contain cycles, so they weren't hitting the old bugs. The question is hot to resolve this so that FileUtils.copyDirectory behaves reasonably with all possible directories whether cycles are present or not. Is there a consistent and reasonable way we can or should copy some links to directories as directories and others as actual directories? There are a number of cases to consider: 1. No symbolic links. Just copy everything and we're good. 2. Symbolic links but only to files, not directories. Copy the file or copy the link? 3. Symbolic links but only to files within the root directory being copied. Right now at head we create a link to the old directory in the source. We could instead create a link to the new directory in the target. 4. Symbolic links to files outside the root directory being copied. Right now at head we
[jira] [Commented] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
[ https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813679#comment-17813679 ] Elliotte Rusty Harold commented on IO-845: -- There are three reasonable cases I can see here: # Don't repoint links. All copied links point to the original files. # Repoint links that target files inside the copied directory. Maintain links that point outside the copied directory. # Actualize files. No links to files are copied. Instead links are replaced by the contents of the files they point to. I think #2 is the least surprising behavior. Possibly we could add an argument that chooses between these behaviors. Another option would be to additional methods independent of the copy that replace a link with its contents, or that walks a directory and replaces all links with its contents. I'd be skeptical of the need for this if we didn't know that Google was already using this. > Copying symbolic links. how should FileUtils.copyDirectory. behave? > --- > > Key: IO-845 > URL: https://issues.apache.org/jira/browse/IO-845 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > The current 2.15.1 release and earlier versions have bugs in the copying of > symbolic link cycles using FileUtils.copyDirectory. There are also bugs in > copying broken symbolic links reported in IO-807. These are fixed at head > because symbolic links to directories are now copied as symbolic links rather > than by resolving the files. However this causes problems for some > non-hypothetical existing code that relied on the old behavior for copying > directories containing non-cyclical symbolic links.In particular, Google has > [reported failures in some of their internal > projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] > when using the version at head as a result of this. However I don't think > that the directories Google is copying contain cycles, so they weren't > hitting the old bugs. > The question is hot to resolve this so that FileUtils.copyDirectory behaves > reasonably with all possible directories whether cycles are present or not. > Is there a consistent and reasonable way we can or should copy some links to > directories as directories and others as actual directories? There are a > number of cases to consider: > 1. No symbolic links. Just copy everything and we're good. > 2. Symbolic links but only to files, not directories. Copy the file or copy > the link? > 3. Symbolic links but only to files within the root directory being copied. > Right now at head we create a link to the old directory in the source. We > could instead create a link to the new directory in the target. > 4. Symbolic links to files outside the root directory being copied. Right now > at head we create a link to the old directory in the source. We should > probably keep this behavior. > I think the behavior we want is as follows, and then I think we handle most > use cases while avoiding cycle problems: > 1. Start from a root directory, the source. > 2. Never copy anything that is not contained in that directory to the target. > 3. When walking the directory tree, if a symbolic link is encountered: >3.1 If the symbolic link points outside the source, create a new symbolic > link to the same target. >3.2 If the symbolic link points to a target inside the source, create a > new symbolic link to the copy of the target. > However every symbolic link in the source turns into a symbolic link in the > copy. Cycles do not cause problems because they are not followed. The only > discrepancy I see in this approach is that a link to a directory outside the > source that is a link that points back into the source still points back into > the source, not the target. Thus the copy can point back into the source > indirectly. Perhaps when copying links that point outside the source we can > fully resolve them to and repoint as needed. > I don't know that this actually fixes Google's problem. They sort of want > files if not directories to be resolved when copying. Maybe that's a > argument. Maybe that's a separate method like > FileUtils.actualizeFiles(directory) that walks a file tree and replaces every > link to a file with the contents of the target file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
[ https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811704#comment-17811704 ] Elliotte Rusty Harold commented on IO-845: -- One way to describe this is that once symlinks are added, the source directory we're copying is a graph rather than a tree. The copied graph should be the same as the source graph. > Copying symbolic links. how should FileUtils.copyDirectory. behave? > --- > > Key: IO-845 > URL: https://issues.apache.org/jira/browse/IO-845 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > The current 2.15.1 release and earlier versions have bugs in the copying of > symbolic link cycles using FileUtils.copyDirectory. There are also bugs in > copying broken symbolic links reported in IO-807. These are fixed at head > because symbolic links to directories are now copied as symbolic links rather > than by resolving the files. However this causes problems for some > non-hypothetical existing code that relied on the old behavior for copying > directories containing non-cyclical symbolic links.In particular, Google has > [reported failures in some of their internal > projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] > when using the version at head as a result of this. However I don't think > that the directories Google is copying contain cycles, so they weren't > hitting the old bugs. > The question is hot to resolve this so that FileUtils.copyDirectory behaves > reasonably with all possible directories whether cycles are present or not. > Is there a consistent and reasonable way we can or should copy some links to > directories as directories and others as actual directories? There are a > number of cases to consider: > 1. No symbolic links. Just copy everything and we're good. > 2. Symbolic links but only to files, not directories. Copy the file or copy > the link? > 3. Symbolic links but only to files within the root directory being copied. > Right now at head we create a link to the old directory in the source. We > could instead create a link to the new directory in the target. > 4. Symbolic links to files outside the root directory being copied. Right now > at head we create a link to the old directory in the source. We should > probably keep this behavior. > I think the behavior we want is as follows, and then I think we handle most > use cases while avoiding cycle problems: > 1. Start from a root directory, the source. > 2. Never copy anything that is not contained in that directory to the target. > 3. When walking the directory tree, if a symbolic link is encountered: >3.1 If the symbolic link points outside the source, create a new symbolic > link to the same target. >3.2 If the symbolic link points to a target inside the source, create a > new symbolic link to the copy of the target. > However every symbolic link in the source turns into a symbolic link in the > copy. Cycles do not cause problems because they are not followed. The only > discrepancy I see in this approach is that a link to a directory outside the > source that is a link that points back into the source still points back into > the source, not the target. Thus the copy can point back into the source > indirectly. Perhaps when copying links that point outside the source we can > fully resolve them to and repoint as needed. > I don't know that this actually fixes Google's problem. They sort of want > files if not directories to be resolved when copying. Maybe that's a > argument. Maybe that's a separate method like > FileUtils.actualizeFiles(directory) that walks a file tree and replaces every > link to a file with the contents of the target file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
[ https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811690#comment-17811690 ] Elliotte Rusty Harold edited comment on IO-845 at 1/28/24 8:47 PM: --- My bad, I meant 2.15.1. https://search.maven.org/artifact/commons-io/commons-io/2.15.1/jar The major versions between commons-lang and commons-io keep throwing me was (Author: elharo): My bad, I meant 2.15.1. https://search.maven.org/artifact/commons-io/commons-io/2.15.1/jar The versions between commons-lang and commons-io keep throwing me > Copying symbolic links. how should FileUtils.copyDirectory. behave? > --- > > Key: IO-845 > URL: https://issues.apache.org/jira/browse/IO-845 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > The current 2.15.1 release and earlier versions have bugs in the copying of > symbolic link cycles using FileUtils.copyDirectory. There are also bugs in > copying broken symbolic links reported in IO-807. These are fixed at head > because symbolic links to directories are now copied as symbolic links rather > than by resolving the files. However this causes problems for some > non-hypothetical existing code that relied on the old behavior for copying > directories containing non-cyclical symbolic links.In particular, Google has > [reported failures in some of their internal > projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] > when using the version at head as a result of this. However I don't think > that the directories Google is copying contain cycles, so they weren't > hitting the old bugs. > The question is hot to resolve this so that FileUtils.copyDirectory behaves > reasonably with all possible directories whether cycles are present or not. > Is there a consistent and reasonable way we can or should copy some links to > directories as directories and others as actual directories? There are a > number of cases to consider: > 1. No symbolic links. Just copy everything and we're good. > 2. Symbolic links but only to files, not directories. Copy the file or copy > the link? > 3. Symbolic links but only to files within the root directory being copied. > Right now at head we create a link to the old directory in the source. We > could instead create a link to the new directory in the target. > 4. Symbolic links to files outside the root directory being copied. Right now > at head we create a link to the old directory in the source. We should > probably keep this behavior. > I think the behavior we want is as follows, and then I think we handle most > use cases while avoiding cycle problems: > 1. Start from a root directory, the source. > 2. Never copy anything that is not contained in that directory to the target. > 3. When walking the directory tree, if a symbolic link is encountered: >3.1 If the symbolic link points outside the source, create a new symbolic > link to the same target. >3.2 If the symbolic link points to a target inside the source, create a > new symbolic link to the copy of the target. > However every symbolic link in the source turns into a symbolic link in the > copy. Cycles do not cause problems because they are not followed. The only > discrepancy I see in this approach is that a link to a directory outside the > source that is a link that points back into the source still points back into > the source, not the target. Thus the copy can point back into the source > indirectly. Perhaps when copying links that point outside the source we can > fully resolve them to and repoint as needed. > I don't know that this actually fixes Google's problem. They sort of want > files if not directories to be resolved when copying. Maybe that's a > argument. Maybe that's a separate method like > FileUtils.actualizeFiles(directory) that walks a file tree and replaces every > link to a file with the contents of the target file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
[ https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811690#comment-17811690 ] Elliotte Rusty Harold commented on IO-845: -- My bad, I meant 2.15.1. https://search.maven.org/artifact/commons-io/commons-io/2.15.1/jar The versions between commons-lang and commons-io keep throwing me > Copying symbolic links. how should FileUtils.copyDirectory. behave? > --- > > Key: IO-845 > URL: https://issues.apache.org/jira/browse/IO-845 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > Through the current 3.15.1 release there are bugs in the copying of symbolic > link cycles using FileUtils.copyDirectory. There are also bugs in copying > broken symbolic links reported in IO-807. These are fixed at head because > symbolic links to directories are now copied as symbolic links rather than by > resolving the files. However this causes problems for some non-hypothetical > existing code that relied on the old behavior for copying directories > containing non-cyclical symbolic links.In particular, Google has [reported > failures in some of their internal > projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] > when using the version at head as a result of this. However I don't think > that the directories Google is copying contain cycles, so they weren't > hitting the old bugs. > The question is hot to resolve this so that FileUtils.copyDirectory behaves > reasonably with all possible directories whether cycles are present or not. > Is there a consistent and reasonable way we can or should copy some links to > directories as directories and others as actual directories? There are a > number of cases to consider: > 1. No symbolic links. Just copy everything and we're good. > 2. Symbolic links but only to files, not directories. Copy the file or copy > the link? > 3. Symbolic links but only to files within the root directory being copied. > Right now at head we create a link to the old directory in the source. We > could instead create a link to the new directory in the target. > 4. Symbolic links to files outside the root directory being copied. Right now > at head we create a link to the old directory in the source. We should > probably keep this behavior. > I think the behavior we want is as follows, and then I think we handle most > use cases while avoiding cycle problems: > 1. Start from a root directory, the source. > 2. Never copy anything that is not contained in that directory to the target. > 3. When walking the directory tree, if a symbolic link is encountered: >3.1 If the symbolic link points outside the source, create a new symbolic > link to the same target. >3.2 If the symbolic link points to a target inside the source, create a > new symbolic link to the copy of the target. > However every symbolic link in the source turns into a symbolic link in the > copy. Cycles do not cause problems because they are not followed. The only > discrepancy I see in this approach is that a link to a directory outside the > source that is a link that points back into the source still points back into > the source, not the target. Thus the copy can point back into the source > indirectly. Perhaps when copying links that point outside the source we can > fully resolve them to and repoint as needed. > I don't know that this actually fixes Google's problem. They sort of want > files if not directories to be resolved when copying. Maybe that's a > argument. Maybe that's a separate method like > FileUtils.actualizeFiles(directory) that walks a file tree and replaces every > link to a file with the contents of the target file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
[ https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated IO-845: - Description: The current 2.15.1 release and earlier versions have bugs in the copying of symbolic link cycles using FileUtils.copyDirectory. There are also bugs in copying broken symbolic links reported in IO-807. These are fixed at head because symbolic links to directories are now copied as symbolic links rather than by resolving the files. However this causes problems for some non-hypothetical existing code that relied on the old behavior for copying directories containing non-cyclical symbolic links.In particular, Google has [reported failures in some of their internal projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] when using the version at head as a result of this. However I don't think that the directories Google is copying contain cycles, so they weren't hitting the old bugs. The question is hot to resolve this so that FileUtils.copyDirectory behaves reasonably with all possible directories whether cycles are present or not. Is there a consistent and reasonable way we can or should copy some links to directories as directories and others as actual directories? There are a number of cases to consider: 1. No symbolic links. Just copy everything and we're good. 2. Symbolic links but only to files, not directories. Copy the file or copy the link? 3. Symbolic links but only to files within the root directory being copied. Right now at head we create a link to the old directory in the source. We could instead create a link to the new directory in the target. 4. Symbolic links to files outside the root directory being copied. Right now at head we create a link to the old directory in the source. We should probably keep this behavior. I think the behavior we want is as follows, and then I think we handle most use cases while avoiding cycle problems: 1. Start from a root directory, the source. 2. Never copy anything that is not contained in that directory to the target. 3. When walking the directory tree, if a symbolic link is encountered: 3.1 If the symbolic link points outside the source, create a new symbolic link to the same target. 3.2 If the symbolic link points to a target inside the source, create a new symbolic link to the copy of the target. However every symbolic link in the source turns into a symbolic link in the copy. Cycles do not cause problems because they are not followed. The only discrepancy I see in this approach is that a link to a directory outside the source that is a link that points back into the source still points back into the source, not the target. Thus the copy can point back into the source indirectly. Perhaps when copying links that point outside the source we can fully resolve them to and repoint as needed. I don't know that this actually fixes Google's problem. They sort of want files if not directories to be resolved when copying. Maybe that's a argument. Maybe that's a separate method like FileUtils.actualizeFiles(directory) that walks a file tree and replaces every link to a file with the contents of the target file. was: Through the current 3.15.1 release there are bugs in the copying of symbolic link cycles using FileUtils.copyDirectory. There are also bugs in copying broken symbolic links reported in IO-807. These are fixed at head because symbolic links to directories are now copied as symbolic links rather than by resolving the files. However this causes problems for some non-hypothetical existing code that relied on the old behavior for copying directories containing non-cyclical symbolic links.In particular, Google has [reported failures in some of their internal projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] when using the version at head as a result of this. However I don't think that the directories Google is copying contain cycles, so they weren't hitting the old bugs. The question is hot to resolve this so that FileUtils.copyDirectory behaves reasonably with all possible directories whether cycles are present or not. Is there a consistent and reasonable way we can or should copy some links to directories as directories and others as actual directories? There are a number of cases to consider: 1. No symbolic links. Just copy everything and we're good. 2. Symbolic links but only to files, not directories. Copy the file or copy the link? 3. Symbolic links but only to files within the root directory being copied. Right now at head we create a link to the old directory in the source. We could instead create a link to the new directory in the target. 4. Symbolic links to files outside the root directory being copied. Right now
[jira] [Resolved] (IO-844) Jira report is out of date
[ https://issues.apache.org/jira/browse/IO-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved IO-844. -- Resolution: Invalid > Jira report is out of date > -- > > Key: IO-844 > URL: https://issues.apache.org/jira/browse/IO-844 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > The page at https://commons.apache.org/proper/commons-io/jira-report.html > hasn't been updated since the 2.x releases over a decade ago. Either figure > out what needs to be turned on to make it current or delete it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IO-844) Jira report is out of date
[ https://issues.apache.org/jira/browse/IO-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed IO-844. > Jira report is out of date > -- > > Key: IO-844 > URL: https://issues.apache.org/jira/browse/IO-844 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > The page at https://commons.apache.org/proper/commons-io/jira-report.html > hasn't been updated since the 2.x releases over a decade ago. Either figure > out what needs to be turned on to make it current or delete it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IO-846) Undeprecate RandomAccessFileInputStream constructors, deprecate the builder
[
https://issues.apache.org/jira/browse/IO-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811688#comment-17811688
]
Elliotte Rusty Harold edited comment on IO-846 at 1/28/24 8:42 PM:
---
So without even looking at the docs as an experienced Java developer what I
expect for XmlStreamReader, or any other reader, is
XmlStreamReader reader = new XmlStreamReader(in);
where in is an InputStream. Of course, in could also be a File, or perhaps a
few other things like a byte array. Now let me look at the docs and see what I
see. Yep, that works.
XmlStreamReader reader = new XmlStreamReader(in);
If I were actually writing code I wouldn't have had to look at the docs. There
are some extra constructors to specify leniency and default encoding, though I
suspect 9 times out of 10 I wouldn't need these. However they wouldn't get in
my way.
As an experienced Java dev I do not expect a builder. I know what a builder is,
and I can figure it out, but probably not without the docs. For instance is it
an inner class? an outer class? Can I construct it or is there some sort of
factory method somewhere? If there is a factory method is it called create or
newInstance or newBuilder or something else? I've seen all of these, and
there's no reliable convention I can use to guide me here. And looking at the
docs it appears all of those are wrong. Apparently I'm supposed to do
XmlStreamReader.setInputStream(in).build().
It is harder to figure out a builder than a constructor. I know the name of
the constructor. I don't know the name or a lot of other details about the
Builder. I can just type the right signature for a constructor. The builder
makes me stop and think about it. The info I need isn't even on one page or in
one class. I have to jump between a lot of superclasses to find the methods i
need. How this is supposed to be better than a one liner I can type in my
sleep, I don't see.
Of course, there are other methods there. Apparently I can also do:
XmlStreamReader reader = XmlStreamReader.setCharacterSequence("some data
here").get().
Except I really shouldn't be able to do that because the whole point of
XmlStreamReader is to convert bytes into chars, not to start with chars. The
superclass hierarchy here doesn't really fit the problem.
There are other ways it doesn't fit. What if I do this:
XmlStreamReader reader = XmlStreamReader.setCharacterSequence("some data
here").setPath("/foo/file.txt").get().
What happens now? I have no idea. Does the character sequence win? The path? Is
one concatenated to the next? Is an exception thrown? If so which exception by
which method? With constructors, I can't even say this.
This is all needlessly complex. Throw away the builders. Throw away the
superclasses. Use boring, ordinary constructors like everyone's been using
since 1995; and the library becomes so much easier to understand, use, and
maintain.
was (Author: elharo):
So without even looking at the docs as an experienced Java developer what I
expect for XmlStreamReader, or any other reader, is
XmlStreamReader reader = new XmlStreamReader(in);
where in is an InputStream. Of course, in could also be a File, or perhaps a
few other things like a byte array. Now let me look at the docs and see what I
see. Yep, that works.
XmlStreamReader reader = new XmlStreamReader(in);
If I were actually writing code I wouldn't have had to look at the docs. There
are some extra constructors to specify leniency and default encoding, though I
suspect 9 times out of 10 I wouldn't need these. However they wouldn't get in
my way.
As an experienced Java dev I do not expect a builder. I know what a builder is,
and I can figure it out, but probably not without the docs. For instance is it
an inner class? an outer class? Can I construct it or is there some sort of
factory method somewhere? If there is a factory method is it called create or
newInstance or newBuilder or something else? I've seen all of these, and
there's no reliable convention I can use to guide me here. And looking at the
docs it appears all of those are wrong. Apparently I'm supposed to do
XmlStreamReader.setInputStream(in).build().
It is harder to figure out a builder than a constructor. I know the name of
the constructor. I don't know the name or a lot of other details about the
Builder. I can just type the right signature for a constructor. The builder
makes me stop and think about it. The info I need isn't even on one page or in
one class. I have to jump between a lot of superclasses to find the methods i
need. How this is supposed to be better than a one liner I can type in my
sleep, I don't see.
Of course, there are other methods there. Apparently I can also do:
XmlStreamReader reader = XmlStreamReader.setCharacterSequence("some data
here").get().
Except I really shouldn't be able to do that
[jira] [Comment Edited] (IO-846) Undeprecate RandomAccessFileInputStream constructors, deprecate the builder
[
https://issues.apache.org/jira/browse/IO-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811688#comment-17811688
]
Elliotte Rusty Harold edited comment on IO-846 at 1/28/24 8:41 PM:
---
So without even looking at the docs as an experienced Java developer what I
expect for XmlStreamReader, or any other reader, is
XmlStreamReader reader = new XmlStreamReader(in);
where in is an InputStream. Of course, in could also be a File, or perhaps a
few other things like a byte array. Now let me look at the docs and see what I
see. Yep, that works.
XmlStreamReader reader = new XmlStreamReader(in);
If I were actually writing code I wouldn't have had to look at the docs. There
are some extra constructors to specify leniency and default encoding, though I
suspect 9 times out of 10 I wouldn't need these. However they wouldn't get in
my way.
As an experienced Java dev I do not expect a builder. I know what a builder is,
and I can figure it out, but probably not without the docs. For instance is it
an inner class? an outer class? Can I construct it or is there some sort of
factory method somewhere? If there is a factory method is it called create or
newInstance or newBuilder or something else? I've seen all of these, and
there's no reliable convention I can use to guide me here. And looking at the
docs it appears all of those are wrong. Apparently I'm supposed to do
XmlStreamReader.setInputStream(in).build().
It is harder to figure out a builder than a constructor. I know the name of
the constructor. I don't know the name or a lot of other details about the
Builder. I can just type the right signature for a constructor. The builder
makes me stop and think about it. The info I need isn't even on one page or in
one class. I have to jump between a lot of superclasses to find the methods i
need. How this is supposed to be better than a one liner I can type in my
sleep, I don't see.
Of course, there are other methods there. Apparently I can also do:
XmlStreamReader reader = XmlStreamReader.setCharacterSequence("some data
here").get().
Except I really shouldn't be able to do that because the whole point of
XmlStreamReader is to convert bytes into chars, not to start with chars. The
superclass hierarchy here doesn't really fit the problem.
There are other ways it doesn't fit. What if I do this:
XmlStreamReader reader = XmlStreamReader.setCharacterSequence("some data
here").setPath("/foo/file.txt").get().
What happens now? I have no idea. Does the character sequence win? The path? Is
one concatenated to the next? Is an exception thrown? If so which exception by
which method? With constructors, I can't even say this.
This is all needlessly complex. Throw away the builders. Throw away the
superclasses. Use boring, ordinary constructors like everyone's
been using since 1995; and the library becomes so much easier to understand,
use, and maintain.
was (Author: elharo):
So without even looking at the docs as an experienced Java developer what I
expect for XmlStreamReader, or any other reader, is
XmlStreamReader reader = new XmlStreamReader(in);
where in is an InputStream. Of course, i could also be a File, or perhaps a few
other things like a ByteSequence. Now let me look at the docs and see what I
see. Yep, that works.
XmlStreamReader reader = new XmlStreamReader(in);
If I were actually writing code I wouldn't have had to look at the docs. There
are some extra constructors to specify leniency and default encoding, though I
suspect 9 times out of 10 I wouldn't need these. However they wouldn't get in
my way.
As an experienced Java dev I do not expect a builder. I know what a builder is,
and I can figure it out, but probably not without the docs. For instance is it
an inner class? an outer class? Can I construct it or is there some sort of
factory method somewhere? If there is a factory method is it called create or
newInstance or newBuilder or something else? I've seen all of these, and
there's no reliable convention I can use to guide me here. And looking at the
docs it appears all of those are wrong. Apparently I'm supposed to do
XmlStreamReader.setInputStream(in).build().
It is harder to figure out a builder than a constructor. I know the name of
the constructor. I don't know the name or a lot of other details about the
Builder. I can just type the right signature for a constructor. The builder
makes me stop and think about it. The info I need isn't even on one page or in
one class. I have to jump between a lot of superclasses to find the methods i
need. How this is supposed to be better than a one liner I can type in my
sleep, I don't see.
Of course, there are other methods there. Apparently I can also do:
XmlStreamReader reader = XmlStreamReader.setCharacterSequence("some data
here").get().
Except I really shouldn't be able to do that
[jira] [Commented] (IO-846) Undeprecate RandomAccessFileInputStream constructors, deprecate the builder
[
https://issues.apache.org/jira/browse/IO-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811688#comment-17811688
]
Elliotte Rusty Harold commented on IO-846:
--
So without even looking at the docs as an experienced Java developer what I
expect for XmlStreamReader, or any other reader, is
XmlStreamReader reader = new XmlStreamReader(in);
where in is an InputStream. Of course, i could also be a File, or perhaps a few
other things like a ByteSequence. Now let me look at the docs and see what I
see. Yep, that works.
XmlStreamReader reader = new XmlStreamReader(in);
If I were actually writing code I wouldn't have had to look at the docs. There
are some extra constructors to specify leniency and default encoding, though I
suspect 9 times out of 10 I wouldn't need these. However they wouldn't get in
my way.
As an experienced Java dev I do not expect a builder. I know what a builder is,
and I can figure it out, but probably not without the docs. For instance is it
an inner class? an outer class? Can I construct it or is there some sort of
factory method somewhere? If there is a factory method is it called create or
newInstance or newBuilder or something else? I've seen all of these, and
there's no reliable convention I can use to guide me here. And looking at the
docs it appears all of those are wrong. Apparently I'm supposed to do
XmlStreamReader.setInputStream(in).build().
It is harder to figure out a builder than a constructor. I know the name of
the constructor. I don't know the name or a lot of other details about the
Builder. I can just type the right signature for a constructor. The builder
makes me stop and think about it. The info I need isn't even on one page or in
one class. I have to jump between a lot of superclasses to find the methods i
need. How this is supposed to be better than a one liner I can type in my
sleep, I don't see.
Of course, there are other methods there. Apparently I can also do:
XmlStreamReader reader = XmlStreamReader.setCharacterSequence("some data
here").get().
Except I really shouldn't be able to do that because the whole point of
XmlStreamReader is to convert bytes into chars, not to start with chars. The
superclass hierarchy here doesn't really fit the problem.
There are other ways it doesn't fit. What if I do this:
XmlStreamReader reader = XmlStreamReader.setCharacterSequence("some data
here").setPath("/foo/file.txt").get().
What happens now? I have no idea. Does the character sequence win? The path? Is
one concatenated to the next? Is an exception thrown? If so which exception by
which method? With constructors, I can't even say this.
This is all needlessly complex. Throw away the builders. Throw away the
superclasses. Use boring, ordinary constructors like everyone's
been using since 1995; and the library becomes so much easier to understand,
use, and maintain.
> Undeprecate RandomAccessFileInputStream constructors, deprecate the builder
> ---
>
> Key: IO-846
> URL: https://issues.apache.org/jira/browse/IO-846
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> The Builder pattern is actively negative here. It introduces at least one
> runtime failure mode (not setting the underlying file) that is a compile time
> error with a constructor. The constructors are simpler, more obvious, and
> less error prone.
> The builder pattern is **not** preferred to constructors in all cases. It is
> a non-standard idiom outside the Java language that is appropriate when:
> 1. There are a large number of arguments.
> 2. At least two of the arguments have the same type so there is a real risk
> of swapping them.
> 3. Any combination of arguments is allowed.
> All three of those conditions are false in this case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
[ https://issues.apache.org/jira/browse/IO-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated IO-845: - Description: Through the current 3.15.1 release there are bugs in the copying of symbolic link cycles using FileUtils.copyDirectory. There are also bugs in copying broken symbolic links reported in IO-807. These are fixed at head because symbolic links to directories are now copied as symbolic links rather than by resolving the files. However this causes problems for some non-hypothetical existing code that relied on the old behavior for copying directories containing non-cyclical symbolic links.In particular, Google has [reported failures in some of their internal projects|https://github.com/apache/commons-io/commit/ec4144b01b4107d6b39f5f4d784cf05217ea4dfa#commitcomment-137567006] when using the version at head as a result of this. However I don't think that the directories Google is copying contain cycles, so they weren't hitting the old bugs. The question is hot to resolve this so that FileUtils.copyDirectory behaves reasonably with all possible directories whether cycles are present or not. Is there a consistent and reasonable way we can or should copy some links to directories as directories and others as actual directories? There are a number of cases to consider: 1. No symbolic links. Just copy everything and we're good. 2. Symbolic links but only to files, not directories. Copy the file or copy the link? 3. Symbolic links but only to files within the root directory being copied. Right now at head we create a link to the old directory in the source. We could instead create a link to the new directory in the target. 4. Symbolic links to files outside the root directory being copied. Right now at head we create a link to the old directory in the source. We should probably keep this behavior. I think the behavior we want is as follows, and then I think we handle most use cases while avoiding cycle problems: 1. Start from a root directory, the source. 2. Never copy anything that is not contained in that directory to the target. 3. When walking the directory tree, if a symbolic link is encountered: 3.1 If the symbolic link points outside the source, create a new symbolic link to the same target. 3.2 If the symbolic link points to a target inside the source, create a new symbolic link to the copy of the target. However every symbolic link in the source turns into a symbolic link in the copy. Cycles do not cause problems because they are not followed. The only discrepancy I see in this approach is that a link to a directory outside the source that is a link that points back into the source still points back into the source, not the target. Thus the copy can point back into the source indirectly. Perhaps when copying links that point outside the source we can fully resolve them to and repoint as needed. I don't know that this actually fixes Google's problem. They sort of want files if not directories to be resolved when copying. Maybe that's a argument. Maybe that's a separate method like FileUtils.actualizeFiles(directory) that walks a file tree and replaces every link to a file with the contents of the target file. was: Through the current 3.15.1 release there are bugs in the copying of symbolic link cycles using FileUtils.copyDirectory. There are also bugs in copying broken symbolic links reported in IO-807. These are fixed at head because symbolic links to directories are now copied as symbolic links rather than by resolving the files. However this causes problems for some non-hypothetical existing code that relied on the old behavior for copying directories containing non-cyclical symbolic links.In particular, Google has reported failures in some of their internal projects when using the version at head as a result of this. However I don't think that the directories Google is copying contain cycles, so they weren't hitting the old bugs. The question is hot to resolve this so that FileUtils.copyDirectory behaves reasonably with all possible directories whether cycles are present or not. Is there a consistent and reasonable way we can or should copy some links to directories as directories and others as actual directories? There are a number of cases to consider: 1. No symbolic links. Just copy everything and we're good. 2. Symbolic links but only to files, not directories. Copy the file or copy the link? 3. Symbolic links but only to files within the root directory being copied. Right now at head we create a link to the old directory in the source. We could instead create a link to the new directory in the target. 4. Symbolic links to files outside the root directory being copied. Right now at head we create a link to the old directory in the source. We should probably keep this behavior. I think the behavior
[jira] [Created] (IO-846) Undeprecate RandomAccessFileInputStream constructors, deprecate the builder
Elliotte Rusty Harold created IO-846: Summary: Undeprecate RandomAccessFileInputStream constructors, deprecate the builder Key: IO-846 URL: https://issues.apache.org/jira/browse/IO-846 Project: Commons IO Issue Type: Bug Components: Streams/Writers Reporter: Elliotte Rusty Harold The Builder pattern is actively negative here. It introduces at least one runtime failure mode (not setting the underlying file) that is a compile time error with a constructor. The constructors are simpler, more obvious, and less error prone. The builder pattern is **not** preferred to constructors in all cases. It is a non-standard idiom outside the Java language that is appropriate when: 1. There are a large number of arguments. 2. At least two of the arguments have the same type so there is a real risk of swapping them. 3. Any combination of arguments is allowed. All three of those conditions are false in this case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-845) Copying symbolic links. how should FileUtils.copyDirectory. behave?
Elliotte Rusty Harold created IO-845: Summary: Copying symbolic links. how should FileUtils.copyDirectory. behave? Key: IO-845 URL: https://issues.apache.org/jira/browse/IO-845 Project: Commons IO Issue Type: Bug Reporter: Elliotte Rusty Harold Through the current 3.15.1 release there are bugs in the copying of symbolic link cycles using FileUtils.copyDirectory. There are also bugs in copying broken symbolic links reported in IO-807. These are fixed at head because symbolic links to directories are now copied as symbolic links rather than by resolving the files. However this causes problems for some non-hypothetical existing code that relied on the old behavior for copying directories containing non-cyclical symbolic links.In particular, Google has reported failures in some of their internal projects when using the version at head as a result of this. However I don't think that the directories Google is copying contain cycles, so they weren't hitting the old bugs. The question is hot to resolve this so that FileUtils.copyDirectory behaves reasonably with all possible directories whether cycles are present or not. Is there a consistent and reasonable way we can or should copy some links to directories as directories and others as actual directories? There are a number of cases to consider: 1. No symbolic links. Just copy everything and we're good. 2. Symbolic links but only to files, not directories. Copy the file or copy the link? 3. Symbolic links but only to files within the root directory being copied. Right now at head we create a link to the old directory in the source. We could instead create a link to the new directory in the target. 4. Symbolic links to files outside the root directory being copied. Right now at head we create a link to the old directory in the source. We should probably keep this behavior. I think the behavior we want is as follows, and then I think we handle most use cases while avoiding cycle problems: 1. Start from a root directory, the source. 2. Never copy anything that is not contained in that directory to the target. 3. When walking the directory tree, if a symbolic link is encountered: 3.1 If the symbolic link points outside the source, create a new symbolic link to the same target. 3.2 If the symbolic link points to a target inside the source, create a new symbolic link to the copy of the target. However every symbolic link in the source turns into a symbolic link in the copy. Cycles do not cause problems because they are not followed. The only discrepancy I see in this approach is that a link to a directory outside the source that is a link that points back into the source still points back into the source, not the target. Thus the copy can point back into the source indirectly. Perhaps when copying links that point outside the source we can fully resolve them to and repoint as needed. I don't know that this actually fixes Google's problem. They sort of want files if not directories to be resolved when copying. Maybe that's a argument. Maybe that's a separate method like FileUtils.actualizeFiles(directory) that walks a file tree and replaces every link to a file with the contents of the target file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-844) Jira report is out of date
Elliotte Rusty Harold created IO-844: Summary: Jira report is out of date Key: IO-844 URL: https://issues.apache.org/jira/browse/IO-844 Project: Commons IO Issue Type: Bug Reporter: Elliotte Rusty Harold The page at https://commons.apache.org/proper/commons-io/jira-report.html hasn't been updated since the 2.x releases over a decade ago. Either figure out what needs to be turned on to make it current or delete it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-187) release current state of master as 1.3
[ https://issues.apache.org/jira/browse/LOGGING-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811358#comment-17811358 ] Elliotte Rusty Harold commented on LOGGING-187: --- The title of this issue is confusing. If it's correct, then that's done. That is, there is a 1.3 release. If this is about releasing 2.0 we should change the title. That said, I agree with the sentiment here. Apache Commons Logging 1.x is a huge source of dependency problems thanks to very outdated logging frameworks. Now that 1.3 is out, I think we should release 2.0 soonish with the following changes: * Remove Avalon & Lumberjack loggers (https://issues.apache.org/jira/browse/LOGGING-173) * Replace log4j 1 with log4j 2 (https://issues.apache.org/jira/browse/LOGGING-180, https://issues.apache.org/jira/browse/LOGGING-181) * Update or remove other dependencies as possible However I don't think we should change the group ID or package names, and I don't think we should require Java 11 yet. The community needs a Java 8 supporting commons-logging that is a drop-in replacement for everyone who isn't using unsupported and two decade old logging frameworks. Otherwise I don't want to break API compatibility in this release. Maybe they're a few deprecated bits here and there no one is using that can also be cleaned up — e.g. default constructors in utility classes or other trivia — but mostly I just want a version of exactly what we have now that works better with 2024 classpaths. > release current state of master as 1.3 > -- > > Key: LOGGING-187 > URL: https://issues.apache.org/jira/browse/LOGGING-187 > Project: Commons Logging > Issue Type: Task >Reporter: Samael Bate >Priority: Major > > master branch appears to be in a good state. Please can someone within Apache > tag/publish a new release so that the following changes can be made as a v2: > * Remove Avalon & Lumberjack loggers > (https://issues.apache.org/jira/browse/LOGGING-173) > * Replace log4j 1 with log4j 2 > (https://issues.apache.org/jira/browse/LOGGING-180, > https://issues.apache.org/jira/browse/LOGGING-181) > * Change _GroupId_ of maven artifact to *org.apache.commons* like other > Apache Commons libs. > * Potentially bump the minimum support JDK (v11 will be needed for recent > logback) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-163) BufferedReader is not closed properly
[
https://issues.apache.org/jira/browse/LOGGING-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810933#comment-17810933
]
Elliotte Rusty Harold commented on LOGGING-163:
---
Not sure why fix version is 1.3.1. Given the dates, I'd expect 1.3.0
> BufferedReader is not closed properly
> -
>
> Key: LOGGING-163
> URL: https://issues.apache.org/jira/browse/LOGGING-163
> Project: Commons Logging
> Issue Type: Bug
>Affects Versions: 1.1.1, 1.2
>Reporter: Kaloyan Spiridonov
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 1.3.1
>
>
> In LogFactory class at line 552 there is BufferedReader that is not closed
> properly. For example if rd.readLine(); throw an exception then the Reader
> will remain open.
> {code}
> BufferedReader rd;
> try {
> rd = new BufferedReader(new InputStreamReader(is, "UTF-8"));
> } catch (java.io.UnsupportedEncodingException e) {
> rd = new BufferedReader(new InputStreamReader(is));
> }
> String factoryClassName = rd.readLine();
> rd.close();
> {code}
> In SimpleLog class at line 163 there is InputStream that is not closed
> properly.
> {code}
> InputStream in = getResourceAsStream("simplelog.properties");
> if(null != in) {
> try {
> simpleLogProps.load(in);
> in.close();
> } catch(java.io.IOException e) {
> // ignored
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IO-843) Deprecate EndianUtils constructor
Elliotte Rusty Harold created IO-843: Summary: Deprecate EndianUtils constructor Key: IO-843 URL: https://issues.apache.org/jira/browse/IO-843 Project: Commons IO Issue Type: Improvement Reporter: Elliotte Rusty Harold It's a static utility class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-842) Deprecate FileUtils.writeLines without charsets
[ https://issues.apache.org/jira/browse/IO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810359#comment-17810359 ] Elliotte Rusty Harold commented on IO-842: -- It's not just apps though. Its libraries too. Imagine I'm a library developer writing code that needs to generate some data according to an official specification, including ones that extend beyond Java. (Not hypothetical. I am a library developer who writes libraries that generate XML among other things.) When I create a method that writes XML (or JSON, or any other well defined format) I know whether I should be writing UTF-8 or ASCII or ISO-8859-1.* It's not a Java question. The spec requires it. That's true no matter what platform I'm on and no matter what system properties or default character set is in scope. Given that, not specifying a character set is a potential hard to diagnose bug. Pre-Java 18 It might show up on some class of machines and not others. Post Java 18 it's even worse because it's much more idiosyncratic and hard to tell why some systems are working and some are breaking. * Yes, XML can be written in multiple character sets but other things have to change when one does so. It's not enough to just output the same string and let the parser guess the encoding. > Deprecate FileUtils.writeLines without charsets > --- > > Key: IO-842 > URL: https://issues.apache.org/jira/browse/IO-842 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > Many of the FileUtils.writeLines methods use the system default encoding and > should be deprecated. This might require providing replacements that do use > an explicit encoding. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-842) Deprecate FileUtils.writeLines without charsets
[ https://issues.apache.org/jira/browse/IO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809929#comment-17809929 ] Elliotte Rusty Harold commented on IO-842: -- No, there are several problems with that: 1. UTF-8 is not always correct or desired, even when it is the platform default character set. 2. JDK 18+ is a small minority of the installed base, and pre-JEP 400 VMs are likely to be with us for the remainder of our careers. 3. Even on JDK 21+ UTF-8 is not guaranteed as the default character set. It can be changed to something else at the VM level. > Deprecate FileUtils.writeLines without charsets > --- > > Key: IO-842 > URL: https://issues.apache.org/jira/browse/IO-842 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > Many of the FileUtils.writeLines methods use the system default encoding and > should be deprecated. This might require providing replacements that do use > an explicit encoding. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-842) Deprecate FileUtils.writeLines without charsets
Elliotte Rusty Harold created IO-842: Summary: Deprecate FileUtils.writeLines without charsets Key: IO-842 URL: https://issues.apache.org/jira/browse/IO-842 Project: Commons IO Issue Type: Bug Reporter: Elliotte Rusty Harold Many of the FileUtils.writeLines methods use the system default encoding and should be deprecated. This might require providing replacements that do use an explicit encoding. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-173) Shall we remove AvalonLogger and LogKitLogger?
[ https://issues.apache.org/jira/browse/LOGGING-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809661#comment-17809661 ] Elliotte Rusty Harold commented on LOGGING-173: --- 1.3.0 is out a couple of months ago. Can we now start moving on breaking changes for 2.0? > Shall we remove AvalonLogger and LogKitLogger? > -- > > Key: LOGGING-173 > URL: https://issues.apache.org/jira/browse/LOGGING-173 > Project: Commons Logging > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > > Do you think it's good idea to move > org.apache.commons.logging.impl.AvalonLogger and > org.apache.commons.logging.impl.LogKitLogger from commons-logging? (logkit is > part of the Avalon project) > I see Apache Avalon project closed in 2004. > https://avalon.apache.org/closed.html > (I'm not suffering from these classes. I found these classes while > [investigating class references using our > tool|https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1871] > and saw the Avalon project has been closed a while ago. I thought it's a > good idea to share the finding here) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-178) Use final variables
[ https://issues.apache.org/jira/browse/LOGGING-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809660#comment-17809660 ] Elliotte Rusty Harold commented on LOGGING-178: --- This should likely be closed. > Use final variables > --- > > Key: LOGGING-178 > URL: https://issues.apache.org/jira/browse/LOGGING-178 > Project: Commons Logging > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOGGING-187) release current state of master as 1.3
[ https://issues.apache.org/jira/browse/LOGGING-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809659#comment-17809659 ] Elliotte Rusty Harold commented on LOGGING-187: --- If we change the group ID to org.apache.commons then we should also change the package names. Otherwise we're opening a barrel full of dependency conflicts and user pain in Java 9+ for the next several years. > release current state of master as 1.3 > -- > > Key: LOGGING-187 > URL: https://issues.apache.org/jira/browse/LOGGING-187 > Project: Commons Logging > Issue Type: Task >Reporter: Samael Bate >Priority: Major > > master branch appears to be in a good state. Please can someone within Apache > tag/publish a new release so that the following changes can be made as a v2: > * Remove Avalon & Lumberjack loggers > (https://issues.apache.org/jira/browse/LOGGING-173) > * Replace log4j 1 with log4j 2 > (https://issues.apache.org/jira/browse/LOGGING-180, > https://issues.apache.org/jira/browse/LOGGING-181) > * Change _GroupId_ of maven artifact to *org.apache.commons* like other > Apache Commons libs. > * Potentially bump the minimum support JDK (v11 will be needed for recent > logback) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-841) Decide if FileUtils.copyFile should copy bytes or symlinks
Elliotte Rusty Harold created IO-841: Summary: Decide if FileUtils.copyFile should copy bytes or symlinks Key: IO-841 URL: https://issues.apache.org/jira/browse/IO-841 Project: Commons IO Issue Type: Bug Reporter: Elliotte Rusty Harold Either way, document it. Note that this question is independent of whether copyDirectory should copy bytes or symlinks, though currently the code might not be independent. Fixing this might require decoupling copyDirectory from copyFile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (LANG-1728) Deprecate EvewntListenerSupport
Elliotte Rusty Harold created LANG-1728: --- Summary: Deprecate EvewntListenerSupport Key: LANG-1728 URL: https://issues.apache.org/jira/browse/LANG-1728 Project: Commons Lang Issue Type: Improvement Components: lang.event.* Reporter: Elliotte Rusty Harold As far as I can tell, despite the name it has nothing to do with event listeners. It simply allows one to sequentially invoke the same method on each member of a list of objects of the same type. There are other ways to do that, including lambdas and executors. This was added circa Java 5/2010 and doesn't fill any particular holes in 2024. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1727) EventListenerSupport doesn't document ordering of events
[ https://issues.apache.org/jira/browse/LANG-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808826#comment-17808826 ] Elliotte Rusty Harold commented on LANG-1727: - There is a test that verifies ordering of listeners, and they appear in the expected order, first in, first fired. Just need to doc it. > EventListenerSupport doesn't document ordering of events > > > Key: LANG-1727 > URL: https://issues.apache.org/jira/browse/LANG-1727 > Project: Commons Lang > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > org.apache.commons.lang3.event.EventListenerSupport needs to document and > test for: > 1. The synchronicity of events; i.e. they're not fired in separate threads > simultaneously > 2. The ordering of events > Adding A, B, and C to EventListenerSupport shouldn't leave devs wondering > whether the events are fired A, B, C or B, C, A or C, B, A. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (LANG-1727) EventListenerSupport doesn't document ordering of events
Elliotte Rusty Harold created LANG-1727: --- Summary: EventListenerSupport doesn't document ordering of events Key: LANG-1727 URL: https://issues.apache.org/jira/browse/LANG-1727 Project: Commons Lang Issue Type: Bug Reporter: Elliotte Rusty Harold org.apache.commons.lang3.event.EventListenerSupport needs to document and test for: 1. The synchronicity of events; i.e. they're not fired in separate threads simultaneously 2. The ordering of events Adding A, B, and C to EventListenerSupport shouldn't leave devs wondering whether the events are fired A, B, C or B, C, A or C, B, A. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-839) Review PathUtils.getBaseName
[ https://issues.apache.org/jira/browse/IO-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806475#comment-17806475 ] Elliotte Rusty Harold commented on IO-839: -- I'd like to see the need for this one. It's sort of a weird thing to do. If there's a need for this beyond one project, fine. Otherwise it's best left in compress. Also https://xkcd.com/927/ applies. Copying the code into commons-io does not remove it from commons-compress. If you're willing to break the API in commons-compress, there are likely better ways to hide idiosyncratic APIs like this one. Mostly just make them non-public. > Review PathUtils.getBaseName > > > Key: IO-839 > URL: https://issues.apache.org/jira/browse/IO-839 > Project: Commons IO > Issue Type: Task >Affects Versions: 2.16.0 >Reporter: Elliotte Rusty Harold >Priority: Blocker > > This method was added to the public API without code review or discussion. > Make sure this makes sense before the next release and either keep, modify, > or remove as decided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-840) Review ChecksumInputStream
Elliotte Rusty Harold created IO-840: Summary: Review ChecksumInputStream Key: IO-840 URL: https://issues.apache.org/jira/browse/IO-840 Project: Commons IO Issue Type: Task Reporter: Elliotte Rusty Harold Fix For: 2.16.0 This was added to the public API without full discussion. It has a single use case in commons compress from where it originates, but it doesn't add a lot to CheckedInputStream. Discuss and consider whether this meets the bar for commons-io public API. Keep or remove as decided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-839) Review PathUtils.getBaseName
Elliotte Rusty Harold created IO-839: Summary: Review PathUtils.getBaseName Key: IO-839 URL: https://issues.apache.org/jira/browse/IO-839 Project: Commons IO Issue Type: Task Affects Versions: 2.16.0 Reporter: Elliotte Rusty Harold This method was added to the public API without code review or discussion. Make sure this makes sense before the next release and either keep, modify, or remove as decided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-805) FilenameUtils.isIPv4Address does not handle illegal integers
[
https://issues.apache.org/jira/browse/IO-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804954#comment-17804954
]
Elliotte Rusty Harold commented on IO-805:
--
Per Wikipedia, "No formal specification of this textual IP address
representation exists." I think the existing code is fine for our purposes.
> FilenameUtils.isIPv4Address does not handle illegal integers
>
>
> Key: IO-805
> URL: https://issues.apache.org/jira/browse/IO-805
> Project: Commons IO
> Issue Type: Bug
>Reporter: Hao Zhong
>Priority: Major
>
> {code:java}
> private static boolean isIPv4Address(final String name) {
> final Matcher m = IPV4_PATTERN.matcher(name);
> if (!m.matches() || m.groupCount() != 4) {
> return false;
> } // verify that address subgroups are legal
> for (int i = 1; i <= 4; i++) {
> final String ipSegment = m.group(i);
> final int iIpSegment = Integer.parseInt(ipSegment);
> if (iIpSegment > IPV4_MAX_OCTET_VALUE) {
> return false;
> } if (ipSegment.length() > 1 &&
> ipSegment.startsWith("0")) {
> return false;
> } } return true;
> } {code}
> In the above code, final int iIpSegment = Integer.parseInt(ipSegment) will
> throw exceptions when ipSegment is illegal.
>
> The nearby isIPv6Address provides an example to handle the problem:
>
> {code:java}
> private static boolean isIPv6Address(final String inet6Address) {
> ...
> try {octetInt = Integer.parseInt(octet, BASE_16);
> } catch (final NumberFormatException e) {
> return false;}
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1725) Conversion should throw IllegalArgumentException instead of IndexOutfBoundsException
[ https://issues.apache.org/jira/browse/LANG-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804555#comment-17804555 ] Elliotte Rusty Harold commented on LANG-1725: - On further investgation, I'm not so sure. The API here is really strange. Since indexes are passed in from client code StringIndexOutOfBoundsException seems appropriate in at least some cases. > Conversion should throw IllegalArgumentException instead of > IndexOutfBoundsException > > > Key: LANG-1725 > URL: https://issues.apache.org/jira/browse/LANG-1725 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Elliotte Rusty Harold >Priority: Major > > see https://github.com/apache/commons-lang/pull/1139 > The original exception should be wrapped. > At least some of these should be NumberFormatException, a subclass of > IllegalArgumentException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-237) Add Additional toFiles() and toURLs() Methods to FileUtils
[ https://issues.apache.org/jira/browse/IO-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804031#comment-17804031 ] Elliotte Rusty Harold commented on IO-237: -- I agree this is not particularly useful. We should close as won't do. > Add Additional toFiles() and toURLs() Methods to FileUtils > -- > > Key: IO-237 > URL: https://issues.apache.org/jira/browse/IO-237 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.0 > Environment: Java 1.5+ >Reporter: Michael Wooten >Priority: Major > Fix For: 3.x > > Attachments: path-convert-fileArray-andURLArray-into-varargs.patch > > Original Estimate: 10h > Remaining Estimate: 10h > > I suggest modifying the signatures of the toFiles() and toURLs() to use > varargs since that approach will automatically accept arrays and also allow > the user to send an arbitrary number of them. > Convert File[] toFiles(URL[]) to File[] toFiles(URL...) > Convert URL[] toURLs(File[]) to URL[] toURLs(File...) > I also suggest adding new methods for converting a collection of URLs or > Files to an array, or to a List. > File[] toFiles(Collection) > List toFilesList(URL...) > List toFilesList(Collection) > URL[] toURLs(Collection) > List toURLsList(File...) > List toURLsList(Collection) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IO-836) FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear
[ https://issues.apache.org/jira/browse/IO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved IO-836. -- Resolution: Fixed > FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear > -- > > Key: IO-836 > URL: https://issues.apache.org/jira/browse/IO-836 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > The existing javadoc and API is very unclear. I do not understand "Gets the > full path from a full fileName, which is the prefix + path, and also > excluding the final directory separator." > The argument is not a filename. There is no such thing as a "full path" in > normal parlance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IO-836) FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear
[ https://issues.apache.org/jira/browse/IO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated IO-836: - Fix Version/s: 2.16.0 > FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear > -- > > Key: IO-836 > URL: https://issues.apache.org/jira/browse/IO-836 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > Fix For: 2.16.0 > > > The existing javadoc and API is very unclear. I do not understand "Gets the > full path from a full fileName, which is the prefix + path, and also > excluding the final directory separator." > The argument is not a filename. There is no such thing as a "full path" in > normal parlance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IO-836) FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear
[ https://issues.apache.org/jira/browse/IO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed IO-836. > FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear > -- > > Key: IO-836 > URL: https://issues.apache.org/jira/browse/IO-836 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > The existing javadoc and API is very unclear. I do not understand "Gets the > full path from a full fileName, which is the prefix + path, and also > excluding the final directory separator." > The argument is not a filename. There is no such thing as a "full path" in > normal parlance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-236) Add "Read" Methods With Size Limits to FileUtils
[ https://issues.apache.org/jira/browse/IO-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803979#comment-17803979 ] Elliotte Rusty Harold commented on IO-236: -- seems like an uncommon need and mostly well handled by other methods and APIs that exist today, including BoundedInputStream. I recommend closing this one as won't do. > Add "Read" Methods With Size Limits to FileUtils > > > Key: IO-236 > URL: https://issues.apache.org/jira/browse/IO-236 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.0 > Environment: 1.4+ >Reporter: Michael Wooten >Priority: Minor > Fix For: 3.x > > Original Estimate: 6h > Remaining Estimate: 6h > > I suggest adding versions of the utility methods for reading lines and > Strings from a file that also accept a limit on the number of bytes or lines > that should be read. I propose that the following methods be added: > String readFileToString(File file, long byteCountToRead) > String readFileToString(File file, String encoding, long byteCountToRead) > byte[] readFileToByteArray(File file, long byteCountToRead) > byte[] readFileToByteArray(File file, String encoding, long byteCountToRead) > List readLines(File file, long lineCountToRead) > List readLines(File file, String encoding, long lineCountToRead) > One of the drawbacks I have encountered to using the methods in the past is > that I only needed to read a limited number of bytes or lines from a file and > I had to read the entire file. This can be especially dangerous if run on a > file that is quite large, and only a portion of the file is needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-250) Add FileUtils.pathTo(File aFile, File fromAnotherFile)
[
https://issues.apache.org/jira/browse/IO-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803978#comment-17803978
]
Elliotte Rusty Harold commented on IO-250:
--
Interesting. Would be careful about testing and handling links.
> Add FileUtils.pathTo(File aFile, File fromAnotherFile)
> --
>
> Key: IO-250
> URL: https://issues.apache.org/jira/browse/IO-250
> Project: Commons IO
> Issue Type: New Feature
> Environment: n/a
>Reporter: Jasper Blues
>Priority: Minor
> Fix For: 3.x
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Please consider adding the following method to
> org.apache.commons.io.FileUtils. I've submitted the method, with test cases
> below (rather than create a patch file). As a single method, it should prove
> very simple to integrate.
> The method returns the path to a file, from another file, as described in the
> Javadoc method header below:
> {code}
> /**
> * Returns the path of a aFile relative to another aFile, for example the
> location of a file:
> * resources/language/english/foobar.properties relative to
> * resources/language/japanese/foobar.properties is
> * ../../english/foobar.properties
> *
> * @param aFile the aFile to check relative location
> * @param fromAnotherFile the base location
> * @return the relative location path
> * @throws java.io.IOException on IO error
> */
> public static String pathTo(File aFile, File fromAnotherFile) throws
> IOException {
> LOGGER.debug("Find path to file: " + aFile.toString() + " from file:
> " + fromAnotherFile.toString());
> Stack fileToDirectories = directoriesFor(aFile);
> Stack fileFromDirectories = directoriesFor(fromAnotherFile);
> while (fileToDirectories.peek().equals(fileFromDirectories.peek())) {
> fileToDirectories.pop();
> fileFromDirectories.pop();
> if (fileToDirectories.isEmpty() || fileFromDirectories.isEmpty())
> {
> break;
> }
> }
> StringBuilder pathToCommonParentDirectory = new StringBuilder();
> while (!fileFromDirectories.isEmpty()) {
> pathToCommonParentDirectory.append("../");
> fileFromDirectories.pop();
> }
> StringBuilder pathToFileFromCommonParentDirectory = new
> StringBuilder();
> while (!fileToDirectories.isEmpty()) {
>
> pathToFileFromCommonParentDirectory.append(fileToDirectories.pop().getName());
> if (!fileToDirectories.isEmpty()) {
> pathToFileFromCommonParentDirectory.append("/");
> }
> }
> return pathToCommonParentDirectory.toString() +
> pathToFileFromCommonParentDirectory.toString();
> }
> private static Stack directoriesFor(File file) throws IOException {
> Stack pathElements = new Stack();
> for (File element = file.getCanonicalFile(); element != null; element
> = element.getParentFile()) {
> pathElements.push(element);
> }
> return pathElements;
> }
> {code}
> . . . this is useful for batch processing, web applications, etc.
> Test Cases:
> {code}
> @Test
> public void pathTo() throws IOException {
> //Setup
> File file1 = new File("configs/js/en/a.xml");
> File file2 = new File("configs/js/ja/a.xml");
> Assert.assertNotNull(file1);
> Assert.assertNotNull(file2);
> //Test
> Assert.assertEquals("../../en/a.xml", FileUtils.pathTo(file1, file2));
> }
> @Test
> public void pathTo_windowsStyleOnUnixMachine() throws IOException {
> File file1 = new File("c:/fred/foobar/dude.properties");
> File file2 = new File("c:/data/zz.txt");
> Assert.assertEquals("../../fred/foobar/dude.properties",
> FileUtils.pathTo(file1, file2));
> Assert.assertEquals("../../../data/zz.txt", FileUtils.pathTo(file2,
> file1));
> }
> @Test
> public void pathTo_fromParentDirectory() throws IOException {
> File file1 = new
> File("ui-performance-enhancer/out/test/ui-performance-enhancer/configs/css/imported.xml");
> File file2 = new
> File("ui-performance-enhancer/out/test/ui-performance-enhancer/configs/css");
> Assert.assertEquals("imported.xml", FileUtils.pathTo(file1, file2));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IO-838) FilenameUtils handling of tilde is borked
Elliotte Rusty Harold created IO-838: Summary: FilenameUtils handling of tilde is borked Key: IO-838 URL: https://issues.apache.org/jira/browse/IO-838 Project: Commons IO Issue Type: Bug Reporter: Elliotte Rusty Harold The tilde ~ is a legal character in Unix and probably Windows file names. It does not mean the home directory. That is a *shell* convention independent of fiule paths and names. FilenameUtils gets this wrong. Figure out what to do about this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-837) Deprecate Filenameutils.equals(String, String)
Elliotte Rusty Harold created IO-837: Summary: Deprecate Filenameutils.equals(String, String) Key: IO-837 URL: https://issues.apache.org/jira/browse/IO-837 Project: Commons IO Issue Type: Improvement Reporter: Elliotte Rusty Harold In favor of Objects.equals -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-836) FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear
[ https://issues.apache.org/jira/browse/IO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803198#comment-17803198 ] Elliotte Rusty Harold commented on IO-836: -- Also what should happen with Unix a root path, a single slash? Return an empty string I suppose. > FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear > -- > > Key: IO-836 > URL: https://issues.apache.org/jira/browse/IO-836 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > The existing javadoc and API is very unclear. I do not understand "Gets the > full path from a full fileName, which is the prefix + path, and also > excluding the final directory separator." > The argument is not a filename. There is no such thing as a "full path" in > normal parlance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-836) FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear
Elliotte Rusty Harold created IO-836: Summary: FileNameUtils.getFullPathNoEndSeparator Javadoc is unclear Key: IO-836 URL: https://issues.apache.org/jira/browse/IO-836 Project: Commons IO Issue Type: Bug Reporter: Elliotte Rusty Harold The existing javadoc and API is very unclear. I do not understand "Gets the full path from a full fileName, which is the prefix + path, and also excluding the final directory separator." The argument is not a filename. There is no such thing as a "full path" in normal parlance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IO-807) FileUtils.requireExists does not take into account soft links
[
https://issues.apache.org/jira/browse/IO-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801816#comment-17801816
]
Elliotte Rusty Harold edited comment on IO-807 at 1/4/24 2:27 PM:
--
After non-exhaustive testing in bash on my Mac, the behavior you're describing
is for hard links. However for symbolic links, the link is copied. The data is
not copied. I suspect that should be our default in the absence of copy options
that say otherwise. That is, when copying a symbolic link to a new location,
create a new symbolic link that points to the same path the original symbolic
link pointed to.
And even for hard links, not quite because hard links can share the same inode
and fiels copied byte per byte don't. We can use Files.createLink to create a
hard link and Files.createSymbolicLink to create a soft link as needed.
was (Author: elharo):
After non-exhaustive testing in bash on my Mac, the behavior you're describing
is for hard links. However for symbolic links, the link is copied. The data is
not copied. I suspect that should be our default in the absence of copy options
that say otherwise. That is, when copying a symbolic link to a new location,
create a new symbolic link that points to the same path the original symbolic
link pointed to.
And even for hard links, not quite because hard links can share the same inode
and fiels copied byte per byte don't.
> FileUtils.requireExists does not take into account soft links
> -
>
> Key: IO-807
> URL: https://issues.apache.org/jira/browse/IO-807
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.13.0
>Reporter: Jordi Sola
>Priority: Major
>
> The current sources for `FileUtils.requireExists` and `FileUtils.
> requireExistsChecked` just check for the existence of the file, delegating to
> the `File.exists` method:
> {code:java}
> Objects.requireNonNull(file, fileParamName);
> if (!file.exists()) {
> throw ...
> }
> return file;{code}
> The default `file` implementation returns `false` if the file is a broken
> symbolic link (that is, a symbolic link pointing to an non-existing file).
> While this implementation can be seen as correct most of the time, sometimes
> we need to avoid following the link, and evaluate the existence of the link
> itself.
> For example, when using `FileUtils#copyDirectory` with the
> `LinkOption.NOFOLLOW_LINKS` option, it is expected that broken links are
> copied (see JavaDocs for `java.nio.file.Files#copy`). Nonetheless, as
> `FileUtils#requireFileIfExists` returns `false`, the file is just ignored.
>
> One possible approach is relying in `java.nio.file.Files#isSymbolicLink` when
> `LinkOption.NOFOLLOW_LINKS` options is provided.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IO-807) FileUtils.requireExists does not take into account soft links
[
https://issues.apache.org/jira/browse/IO-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801816#comment-17801816
]
Elliotte Rusty Harold edited comment on IO-807 at 1/4/24 2:25 PM:
--
After non-exhaustive testing in bash on my Mac, the behavior you're describing
is for hard links. However for symbolic links, the link is copied. The data is
not copied. I suspect that should be our default in the absence of copy options
that say otherwise. That is, when copying a symbolic link to a new location,
create a new symbolic link that points to the same path the original symbolic
link pointed to.
And even for hard links, not quite because hard links can share the same inode
and fiels copied byte per byte don't.
was (Author: elharo):
After non-exhaustive testing in bash on my Mac, the behavior you're describing
is for hard links. However for symbolic links, the link is copied. The data is
not copied. I suspect that should be our default in the absence of copy options
that say otherwise. That is, when copying a symbolic link to a new location,
create a new symbolic link that points to the same path the original symbolic
link pointed to.
> FileUtils.requireExists does not take into account soft links
> -
>
> Key: IO-807
> URL: https://issues.apache.org/jira/browse/IO-807
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.13.0
>Reporter: Jordi Sola
>Priority: Major
>
> The current sources for `FileUtils.requireExists` and `FileUtils.
> requireExistsChecked` just check for the existence of the file, delegating to
> the `File.exists` method:
> {code:java}
> Objects.requireNonNull(file, fileParamName);
> if (!file.exists()) {
> throw ...
> }
> return file;{code}
> The default `file` implementation returns `false` if the file is a broken
> symbolic link (that is, a symbolic link pointing to an non-existing file).
> While this implementation can be seen as correct most of the time, sometimes
> we need to avoid following the link, and evaluate the existence of the link
> itself.
> For example, when using `FileUtils#copyDirectory` with the
> `LinkOption.NOFOLLOW_LINKS` option, it is expected that broken links are
> copied (see JavaDocs for `java.nio.file.Files#copy`). Nonetheless, as
> `FileUtils#requireFileIfExists` returns `false`, the file is just ignored.
>
> One possible approach is relying in `java.nio.file.Files#isSymbolicLink` when
> `LinkOption.NOFOLLOW_LINKS` options is provided.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1725) Conversion should throw IllegalArgumentException instead of IndexOutfBoundsException
[ https://issues.apache.org/jira/browse/LANG-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated LANG-1725: Description: see https://github.com/apache/commons-lang/pull/1139 The original exception should be wrapped. At least some of these should be NumberFormatException, a subclass of IllegalArgumentException. was: see https://github.com/apache/commons-lang/pull/1139 The original exception should be wrapped > Conversion should throw IllegalArgumentException instead of > IndexOutfBoundsException > > > Key: LANG-1725 > URL: https://issues.apache.org/jira/browse/LANG-1725 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Elliotte Rusty Harold >Priority: Major > > see https://github.com/apache/commons-lang/pull/1139 > The original exception should be wrapped. > At least some of these should be NumberFormatException, a subclass of > IllegalArgumentException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (LANG-1725) Conversion should throw IllegalArgumentException instead of IndexOutfBoundsException
Elliotte Rusty Harold created LANG-1725: --- Summary: Conversion should throw IllegalArgumentException instead of IndexOutfBoundsException Key: LANG-1725 URL: https://issues.apache.org/jira/browse/LANG-1725 Project: Commons Lang Issue Type: Bug Components: lang.* Reporter: Elliotte Rusty Harold see https://github.com/apache/commons-lang/pull/1139 The original exception should be wrapped -- This message was sent by Atlassian Jira (v8.20.10#820010)
