[
https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534541
]
Niall Pemberton commented on IO-128:
------------------------------------
Stephen, thanks for helping with this...
"I believe that the intention was that all invalid inputs would result in null,
not an exception, so the fix is incorrect. (But it should also not throw NPE)"
The problem is in the equals method which returns a primitive boolean, so
returning null is not an option. It calls the normalize() method on the file
names, so the question is what should that method do if the "normalized" file
names are null? Currently it causes a confusing NPE - if an exception is not
correct in the equals method then the question is what to do? Perhaps it should
continue, but use the un-normalized file name for any that are invalid?
"Two options:
a) clarify that if the double slash is at the start, it has to refer to a UNC
name
b) handle the case that a double slash at the start should be just normalized
to a single slash if it is not a UNC name."
Seems to me that since the current "normalize" contract is to return null for
invalid names then isn't option b) effectively changing the contract of that
method? Or is it that although a file name such as //foo.txt is not a valid UNC
name - it should be considered a valid file name?
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at
> org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at
> org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at
> org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is
> not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an
> exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
