>but chmod command doesn't recognize NON-ASCII characters. Even if I
>give NON-ASCII-ESCAPED characters like
>/\343\201\202\343\201\204\343\201\206\343\201\210\343\201\212.txt ,
>it doesn't work.
The problem is not in 'chmod'. The problem is probably in how your Java
source file is compiled.
When you have any non-ASCII characters in a .java source file, you have to
make sure the compiler will read those characters using the proper text
encoding. The default text encoding of the 'javac' compiler is probably
NOT the same as the text encoding the source file was saved as. As a
result, the literal String that gets compiled into the .class file doesn't
have the right characters in it, which means there isn't a file with that
name, so 'chmod' fails. In a nutshell, 'chmod' is working, but the String
you're giving it is wrong.
Relying on source-file text encoding at compile-time is risky, because it
makes proper interpretation of the source dependent on an external setting:
the compiler's default text encoding. That's bad, but not because it can't
be controlled by the build process. It's bad because source text-encoding
isn't usually specified for the build process, so compilation usually runs
with the default encoding, and that default will vary by the user's primary
language, platform, or other variables. Since you haven't said what your
primary language is, nor how you're compiling your source file, I can't
tell you what to change to make your original source compile correctly.
In general, you should use Unicode escapes for all characters outside the
range U0020 thru U007F. If you had used Unicode escapes instead of octal
escapes, it probably would have worked (except that the file itself also
needs to exist).
Your example of octal escapes suggests you may think UTF-8 is the encoding
for literal strings. It's not. You should use Java's Unicode escape
notation, which is \u followed by a 4-digit hex number representing the
Unicode code point in UTF-16. I can't tell you exactly what the correct
escapes are, because I don't read Japanese. You can look them up at
www.unicode.org, or you can save your source file as 16-bit Unicode, then
use the 'hexdump' command to dump the text, and figure out the correct
Unicode escapes that way.
(* Sidebar: It would be nice to have a service under the Services menu that
takes a selection and returns the Java-source Unicode escapes for it, which
also happen to be JavaScript-source Unicode escapes. Or maybe there is
already such a thing, and I haven't heard of it. *)
> bos.write (("chmod " + (recursive ? "-R " : "") + auth + " \"" +
>path.getCanonicalPath () + "\"\n").getBytes ("UTF-8"));
This code is dangerous because you are not quoting the path properly. In
particular, you aren't handling the case where the pathname itself contains
double-quotes or $. This is a remarkably dangerous thing to do. It's
pretty easy to exploit it to cause damage. It's also not difficult for it
to accidentally cause damage.
To see the problem, consider the following code fragment:
File deadly = new File( "/Users/Shared/\";rm -fr $HOME\"" );
deadly.mkdirs();
YourExample.chmod( deadly, "g+w", false );
DO NOT RUN THIS. It will delete something very valuable to you, leaving
only a mocking folder-name in /Users/Shared.
Analyze this for its implications, then go back to exec()'ing 'chmod'
directly. Using an overpowered tool for simple tasks can lead to
unexpected explosions.
This general class of problems is called "command injection". A common
version of it is SQL injection, but it applies to any situation where
commands and literal operands are interpreted from text:
<http://en.wikipedia.org/wiki/Sql_injection>
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
