Re: Lock a file or somehow make it unwritable
Lionel van den Berg wrote:
On Jul 31, 11:05 am, Arne Vajh?j <a...@vajhoej.dk> wrote:
Lionel van den Berg wrote:
On Jul 31, 8:58 am, Arne Vajh?j <a...@vajhoej.dk> wrote:
Lionel van den Berg wrote:
I'm building a test harness and would like to lock a particular file
so that when the system under test tries to write to this file it
cannot. I was looking at FileChannel but (un)fortunately that locks it
for the entire VM, so it doesn't affect any later calls.
Any ideas on solutions?
Have you tried opening it for write as a lock?
Yes, here is a sample of the code I have tried:
final File file = new File(filePath);
// Create the file or we won't get a lock.
file.createNewFile();
final FileOutputStream fileOutputStream = new FileOutputStream(file);
final FileLock fileLock = fileOutputStream.getChannel().lock();
if (fileLock == null) {
writeString("Failed to acquire lock on \"" + filePath + "\".");
} else {
fileLocks.add(fileLock);
}
But when you look at the documentation for FileChannel the following
gives away the secret:
"File locks are held on behalf of the entire Java virtual machine.
They are not suitable for controlling access to a file by multiple
threads within the same virtual machine. "
Your original question stated that you wanted to prevent the
test code from writing to the file.
I've re-read my original post and I can't really come to that
conclusion:
"so that when the system under test tries to write to this file it
cannot"
The system under test, not the test code.
Anyway, there was obviously confusion that's why I restated.
I can not really see how the above correlates to that.
Nor can I see how you came to your interpretation.
You were talking about creating a situation where
attempting to write to a file is not possible.
You test code tries to acquire a lock instead of writing.
I can not see how the test related to your stated goal.
Some experimentation shows that FileOutputStream does
not lock the file exclusively.
But .getChannel().lock() as in your code works (if used
for locking and not for test).
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.nio.channels.FileLock;
public class Lock {
public static OutputStream uselessLock(File f) throws IOException {
return new FileOutputStream(f, true);
}
public static FileLock workingLock(File f) throws IOException {
return new FileOutputStream(f, true).getChannel().lock();
}
public static void main(String[] args) throws Exception {
File f = new File("C:\\z.z");
f.createNewFile();
//uselessLock(f);
workingLock(f);
OutputStream os = new FileOutputStream(f, true);
os.write(123);
os.close();
}
}
did result in:
Exception in thread "main" java.io.IOException: The process cannot
access the file because another process has locked a portion of the file
which I assume is what you want.
It's exactly what I want which confuses me to why it didn't work the
way I was using it. But doesn't that behaviour violate the Javadoc
statement? http://java.sun.com/javase/6/docs/api/
again:
"File locks are held on behalf of the entire Java virtual machine.
They are not suitable for controlling access to a file by multiple
threads within the same virtual machine. "
This isn't even multiple threads, doesn't that say it should not work,
or does it suggest that you can't trust it to work?
I'm going to go back and try again - although my solution is working,
I might actually want to do it both ways.
I think it means that the Java specs does not guarantee that
the locking technique above will work.
But there are very few guarantees about the locking stuff at
all, because it is so OS specific.
Arne