Fwd: 7050570: (fs) FileSysteProvider fails to initializes if run with file.encoding set to Cp037

[Ulf Zibis]

Hi,

shouldn't we better code? :
-53         if (this.defaultDirectory[0] != '/') {
+53         if (this.defaultDirectory[0] != (byte)'/') {
It would make it more clear to the reader, that only single bytes are compared here, and maybe would 
prevent from the problem when "source code encoding != platform encoding".
At least there should be an explaining comment.

But why not simply? :
   51         this.provider = provider;
   52         String normalizedDir = UnixPath.normalizeAndCheck(dir);
   53         if (normalizedDir.charAt(0) != '/') {
   54             throw new RuntimeException("default directory must be absolute");
   55         }
   52         this.defaultDirectory = Util.toBytes(normalizedDir);

Anyway there already is UnixPath.isAbsolute() to use.

Similar in SolarisUserDefinedFileAttributeView.
But anyway better code:

   45     private static final byte[] HERE = Util.toBytes(".");
   46
   47     private byte[] nameAsBytes(UnixPath file, String name) throws IOException {
   48         byte[] bytes = Util.toBytes(name);
   49         //  "", "." and ".." not allowed
   50         if (bytes.length == 0 || (bytes[0] == '.' &&
   51                 (bytes.length == 1 || (bytes.length == 2 && bytes[1] == '.'))) {
   52       ....

-Ulf


Am 27.08.2012 00:05, schrieb Xueming Shen:
> Alan, change looks fine.
>
> Is there possibility that SolarisUserDefinedFileAttributeView might be used/compiled
> for a non-ascii based, for example ebcdic, platform. It might be a potential problem
> if the source code is compiled with encoding flag -ascii and be targeted for a non-ascii
> platform. Otherwise, not an issue.
>
> -Sherman
>
>> Subject: 	7050570: (fs) FileSysteProvider fails to initializes if run with file.encoding set to 
>> Cp037
>> Date: 	Wed, 15 Aug 2012 13:05:55 +0100
>> From: 	Alan Bateman <Alan.Bateman at oracle.com>
>> To: 	nio-dev <nio-dev at openjdk.java.net>
>>
>>
>>
>>
>> This is another one that has been in my patch queue for a while, actually from before jdk7 
>> shipped as it arose with someone trying tests with file.encoding set on the command line 
>> (something that has never been supported but sometimes useful for tests). It's also an issue that 
>> came up recently on the core-libs list [1] where someone was trying to do something similar.
>>
>> The changes here just change the file system provider to use sun.jnu.encoding property as the 
>> charset to use when encoding/decoding file names. I think eventually we should be use this 
>> consistently and leaving file.encoding to the file content. The assumption remains in the code 
>> that there aren't any locales that map to UTF-16 or other encoding that require shift in/out. If 
>> there were such a locale then more further changes would be required in order to deal with 
>> multi-byte slash a few others used in the code.
>>
>> Sherman - I think you would be the best person to review this. The webrev with the changes is here:
>> http://cr.openjdk.java.net/~alanb/7050570/webrev/
>>
>> -Alan.
>>
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010758.html 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120827/47ccbc8b/attachment.html