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

Ulf Zibis Ulf.Zibis at CoSoCo.de
Mon Aug 27 02:53:09 PDT 2012

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

More information about the nio-dev mailing list