本文发表在 rolia.net 枫下论坛The following is my understanding of file locking problem in Java. It might
be wrong.
1) What is a file? A file is a resource, just like a database. So sometimes
we need to pretect it from getting destroyed.
2) In Java, a file at the native machine, as a resource, is wrapped into an Object, ---a File,
or FileInpuStream, or FileOutputStream, or FileReader, or FileWriter, or RandomAccessFile...
Some notes are in order here. a) If we use a File, we can use its public boolean setReadOnly()
to make it readable only. This is not guaranteed to succeed, because the true file is out of the JVM.
The caller of this method may fail because of the constraints of SecurityManager. If we succeed, the
method return true; otherwise, it return false. b) If we create a RandomAccessFile, we may specify
whether it is readable only or can be writable, too. Both a) and b) provide some ways to protect
the file on the machine.
3) The key word "synchronized" cannot be used to protect a file from being used by others.
Look at the following code:
File file = new File("xxx.txt");
synchronized(file) { // operate on the file }
Here JVM locks the File object (the wrapper of the real file) in JVM, not the real file on the
operating system. One can cook up some code to confirm my statement here.
4) Java Application (Applet, Servlet, EJB, ...) is only a process running on the native machine.
The file is a resource on the native machine. Asking for a flock() function or something like it
means to assign too much power to JVM. I GUESS this is one of the reasons that Java designers did not
follow C/C++ here.
5) In JVM, there is a SecurityManager. If we don't set a SecurityManger, JVM uses its default one.
SecurityManger uses a policy file, which we can find one under JDK. SecurityManager does a lot of
things, including assigning permission to operate on files. Just remind there is class
called java.io.FilePermission. One needs to define it in policy files. If we just run some
small examples, we seldom think about SecurityManager and policy files in Java.
6) The constructors of the File related Java class throw a checked Exception called
java.io.FileNotFoundException. This implies that java.io.* pakacgae has a very conservative
design. Even the File is there on the native machine, it may not be available to us because of
Security constraints. In turn, the power of locking, deleting, modifying a file is
ultimately on the opertating system, on in the JVM. on the Java side, what we can do is
to try to do something on the file. For instance, create a FileWriter and append some words
to the real file on the operating system. However, this may fail if the system adminstrator
have set the file to be readable only, even the SecurityManager allow us to write to the file.
7) While Java design is so conservative with I/O? The answer is that Java is a networking
language. In the distributed computing, people cannot allow Java has the same power as the
operating system in dealing with the files.
8) How far can we go in protecting a file? Since the file is a kind of resources,
it usually should be shared. Locking a file as is done in C/C++ is too extreme.
What Java can do is to ask its citizens---Java objects-- not to touch a certain file
by use of policy file. Let me say there is a file called report.txt. Java has no luxury to say
"hey, I am using it, you guys (Notepad, Textpad, WrdPad) don't touch it).
A Java appication cannot be as powerful as an operating system. The File class
has a setReadOnly() method because this is a harmless operation. However, it does not have
something like setWritable(). If we want to make a file writable first to JVM, we should
first change its previleg on the operating system, then carefully define policy file
and grant write previlege to the right Java objects.
9) Please don't criticise Java too early. We are Java lerners, not experts. My suggest is that
we think more about security in the system.更多精彩文章及讨论，请光临枫下论坛 rolia.net
be wrong.
1) What is a file? A file is a resource, just like a database. So sometimes
we need to pretect it from getting destroyed.
2) In Java, a file at the native machine, as a resource, is wrapped into an Object, ---a File,
or FileInpuStream, or FileOutputStream, or FileReader, or FileWriter, or RandomAccessFile...
Some notes are in order here. a) If we use a File, we can use its public boolean setReadOnly()
to make it readable only. This is not guaranteed to succeed, because the true file is out of the JVM.
The caller of this method may fail because of the constraints of SecurityManager. If we succeed, the
method return true; otherwise, it return false. b) If we create a RandomAccessFile, we may specify
whether it is readable only or can be writable, too. Both a) and b) provide some ways to protect
the file on the machine.
3) The key word "synchronized" cannot be used to protect a file from being used by others.
Look at the following code:
File file = new File("xxx.txt");
synchronized(file) { // operate on the file }
Here JVM locks the File object (the wrapper of the real file) in JVM, not the real file on the
operating system. One can cook up some code to confirm my statement here.
4) Java Application (Applet, Servlet, EJB, ...) is only a process running on the native machine.
The file is a resource on the native machine. Asking for a flock() function or something like it
means to assign too much power to JVM. I GUESS this is one of the reasons that Java designers did not
follow C/C++ here.
5) In JVM, there is a SecurityManager. If we don't set a SecurityManger, JVM uses its default one.
SecurityManger uses a policy file, which we can find one under JDK. SecurityManager does a lot of
things, including assigning permission to operate on files. Just remind there is class
called java.io.FilePermission. One needs to define it in policy files. If we just run some
small examples, we seldom think about SecurityManager and policy files in Java.
6) The constructors of the File related Java class throw a checked Exception called
java.io.FileNotFoundException. This implies that java.io.* pakacgae has a very conservative
design. Even the File is there on the native machine, it may not be available to us because of
Security constraints. In turn, the power of locking, deleting, modifying a file is
ultimately on the opertating system, on in the JVM. on the Java side, what we can do is
to try to do something on the file. For instance, create a FileWriter and append some words
to the real file on the operating system. However, this may fail if the system adminstrator
have set the file to be readable only, even the SecurityManager allow us to write to the file.
7) While Java design is so conservative with I/O? The answer is that Java is a networking
language. In the distributed computing, people cannot allow Java has the same power as the
operating system in dealing with the files.
8) How far can we go in protecting a file? Since the file is a kind of resources,
it usually should be shared. Locking a file as is done in C/C++ is too extreme.
What Java can do is to ask its citizens---Java objects-- not to touch a certain file
by use of policy file. Let me say there is a file called report.txt. Java has no luxury to say
"hey, I am using it, you guys (Notepad, Textpad, WrdPad) don't touch it).
A Java appication cannot be as powerful as an operating system. The File class
has a setReadOnly() method because this is a harmless operation. However, it does not have
something like setWritable(). If we want to make a file writable first to JVM, we should
first change its previleg on the operating system, then carefully define policy file
and grant write previlege to the right Java objects.
9) Please don't criticise Java too early. We are Java lerners, not experts. My suggest is that
we think more about security in the system.更多精彩文章及讨论，请光临枫下论坛 rolia.net