Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X
Xueming Shen
xueming.shen at oracle.com
Sat Jun 23 04:09:48 UTC 2012
On 6/22/12 11:02 AM, Mike Duigou wrote:
> On Jun 22 2012, at 10:01 , Xueming Shen wrote:
>
>> Hi
>>
>> Here is the proposed change to support Unicode nfd/nfc and case insensitive
>> file path on MacOSX file system.
>>
>> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X
>> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx]
>>
>> While these two bug reports are only against java.io, we have the same issue in javax.nio.file.
>> Here is the webrev
>>
>> (3) fs.compare()/hashCode() was updated to be case insensitive
> Won't this cause problems on case sensitive file systems? The MacOSX filesystem is by default case insensitive but case sensitive file systems are not entirely uncommon.
>
>
Yes, it might/will cause problem on case sensitive hfs+ file system, but
this use scenario
is not this patch tries to address. On MacOSX you can format one of your
disks to be case
sensitive (create a new disk image and set the format to be case
sensitive, via the Disk
Utility, for example) or you might be able to configure your whole HFS+
file system to be
case sensitive, which means the case sensitiveness is actually one of
the attributes of the
volume (FileStore, in JSR203's term), not the whole file system. But the
file system has its
default setting regarding the path case sensitiveness. On HFS+ it's case
insensitive. This
is actually not a unique problem of MacOS file system, you can mount a
Windows FAT32
drive on LInux or vise versa, it's a difficult issue. The JSR-203's
solution is to use the
Path + FileSystem to "modle and be consistent with the platform's
virtual file system, not
the specific underlying file system", so this means on Unix/Linux, the
path matching is
case sensitive, on Windows it's case insensitive and on MacOSX, we go
with the default
case_insensitive.
That said, an alternative is to set the default case sensitiveness
behavior bases on the
setting of the volume that the default file system is mounted on, if the
root is on a
volume that has case sensitive, then the MaxOSXFileSystem is case
sensitive. The code
to detect the volume's case sensitive setting is currently committed
out. Alan and I
chatted about this, we agreed that this is out of the scope of this
patch, we can leave
that for a future enhancement.
-Sherman
More information about the core-libs-dev
mailing list