Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly
peter.levart at gmail.com
Wed Feb 27 12:07:05 UTC 2013
On 02/27/2013 03:52 AM, David Holmes wrote:
> On 27/02/2013 12:31 PM, Dan Xu wrote:
>> Thank you, Mike.
>> The reason not to throw out an exception is for the backward
>> compatibility. Due to that, the constructorof File object with NUL
>> willnever fail.While in NIO, it is defined in the spec to throw out
>> exceptions when invalid NUL character is found.
> That still gives the choice of deleting the nul characters, or
> treating them as a terminator.
> And do we really want/need to maintain compatability in this case
> anyway? What reasonable expectations can anyone have if they have
> embedded nuls?
What does a FileInputStream for example do when trying to open a File
with embedded NUL chars on UNIX/Windows ? Does it try to open a
"truncated" path? If so, then perhaps "normalize" could do that
>> On 02/26/2013 04:33 PM, Mike Duigou wrote:
>>> Hi Dan;
>>> External link to the bug (will hopefully work soon):
>>> I would like to better understand why silently removing the garbage
>>> null characters is the right answer here.
>>> If null is an invalid character for the underlying operating system or
>>> filesystem then perhaps an error should be signalled.
>>> On Feb 26 2013, at 16:10 , Dan Xu wrote:
>>>> Hi All,
>>>> Please help review the fix for JDK-8003992: File and other classes in
>>>> java.io do not handle embedded nulls properly.
>>>> Java IO, not like NIO, does not check NUL character in the given file
>>>> path name, which brings confusion to Java users. This fix is going to
>>>> address this issue by removing any NUL character from the given file
>>>> path. And it also cleans and optimizes the path-name normalization
>>>> logic. Thanks!
>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8003992
>>>> webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.00/
More information about the core-libs-dev