On 5/3/13 6:48 AM, Alan Bateman wrote:
On 03/05/2013 00:08, Dan Xu wrote:
Hi All,
Thanks for all your comments. Based on the previous feedback, I have
moved to the other approach, i.e., to fail file operations if the
invalid NUL characher is found in a file path. As you know, due to
the compatibility issue, we cannot throw an exception immediately in
the File constructors. So the failure is delayed and only shown up
when any file operation is triggered.
As for FileInputStream, FileOutputStream, and RandomAccessFile
classes, the FileNotFoundException will be thrown right away since
their spec allow this exception happen in the constructors. Thanks
for your review!
webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.01/
-Dan
This looks much better. I guess a Boolean would have worked as well as
adding the PathStatus enum but what you have seems okay.
It would be good to get Sherman's confirmation that we don't need to
be concerned about anything else encoding to include NUL.
-Alan.
The change looks fine. I don't see any encoding issue, though this
reminds me one
possible use scenario. Do we want to make it path "valid", if the NUL is
at the end
of the path? This should not been an issue normally though, everything from
the native does not have it. Just wonder if this scenario might work
before (?), with
no potential vuln risk (?), we may want to keep it? No, I don't know
any real code
has the NUL attached to the end, just a wild guess. It's definitely fine
to wait for
any complain, if there will be, and then react.
-Sherman
