问题描述
我正在尝试使用文件锁定，我遇到了一个问题:锁定文件后，至少在某种程度上，其他进程仍然可以访问它.
I'm trying to lock a file with Java in Windows environment with FileLock and I got an issue :after I lock the file it can still be accessed by other processes at least on some level.
示例代码如下:
public class SimpleLockExample {
public static void main(String[] args) throws Exception {
String filename = "loremlipsum.txt";
File file = new File(filename);
RandomAccessFile raf = new RandomAccessFile(file, "rw");
FileChannel channel = raf.getChannel();
FileLock lock = null;
try {
lock = channel.tryLock();
String firstLine = raf.readLine();
System.out.println("First line of file : " + firstLine);
waitForEnter();
lock.release();
} catch (OverlappingFileLockException e) {
e.printStackTrace();
}
lock.release();
System.out.println("Lock released");
channel.close();
}
private static void waitForEnter() throws Exception {
BufferedReader reader =
new BufferedReader(new InputStreamReader(System.in));
reader.readLine();
reader.close();
}
}
现在，当我使用此示例锁定文件时，该文件已被锁定:
Now, when I lock my file with this example, it is locked :
- 它不能被Windows删除
- Eclipse拒绝打开它
...但是还不是完全防弹:
... but it isn't still totally bulletproof:
- 例如，如果我使用Scite(文本编辑器)打开它，则不会显示任何内容，但是如果我选择保存文件(打开时为空或写入了一些内容)，它将成功并且文件的内容为已清除...(即使我用Scite编写过内容，之后也没有内容)
是否有某种方法可以防止Windows中使用Java的其他进程完全覆盖/清除文件?
Is there some way to prevent the file totally from being overwritten/cleared by other processes with Java in Windows?
如果我理解正确，那么我正在使用排他锁atm.使用共享锁，甚至可以做更多的事情.
If I've understood right, I'm using exclusive lock atm. With shared lock there are even more things that can be done.
此测试是在Windows 2000上运行的.
This test was run with Windows 2000.
br，桃子
推荐答案
棘手的是，FileLock API本身并不能提供太多帮助:
Tricky, the FileLock API itself doesn't promise much:
实际上是否有锁 防止其他程序 访问被锁定的内容 区域取决于系统并且 因此未指定.本地人 一些文件的锁定功能 系统仅仅是建议性的，意思是 程序必须合作 遵守以下已知的锁定协议 为了保证数据的完整性.在 其他系统本机文件锁是 强制性的，这意味着如果一个程序 锁定文件的区域，然后锁定其他 程序实际上被阻止 以某种方式进入该地区 会违反锁.在其他 系统，本机文件锁定是否 咨询性或强制性是可配置的 基于每个文件.确保 一致和正确的行为 平台，强烈建议 该API提供的锁是 就像它们是咨询锁一样使用.
Whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and therefore unspecified. The native file-locking facilities of some systems are merely advisory, meaning that programs must cooperatively observe a known locking protocol in order to guarantee data integrity. On other systems native file locks are mandatory, meaning that if one program locks a region of a file then other programs are actually prevented from accessing that region in a way that would violate the lock. On yet other systems, whether native file locks are advisory or mandatory is configurable on a per-file basis. To ensure consistent and correct behavior across platforms, it is strongly recommended that the locks provided by this API be used as if they were advisory locks.
奇怪的是，有关文件锁定API的开发讨论声称，Windows操作系统提供了强制锁定，并且仅在Unix上提供了咨询性锁定.因此，在阅读此书时，您可能希望您的代码在Windows上能正常工作.
Oddly enough, the discussion about the file locking API when it was under development claimed that Windows OS provided mandatory locking and on Unix only advisory locking. So on that reading one might expect your code to work just fine on Windows.
我想知道发生了什么事吗，您的编辑器没有像创建临时文件那样大量地修改文件，而是操纵目录项以便用新版本替换您锁定的文件的版本. Windows会允许这种行为吗?
I wonder if what is happening it that your editor is not so much modifying the file as creating a temporary file and then manipulating directory entries in order to replce the version of the file you have locked with a new version. Would Windows allow such behaviour?
我想知道您是否需要诉诸JNI才能获得所需的控制级别.
I wonder if you'll need to resort to JNI in order to get the level of control you need.
这篇关于Java文件锁定和Windows-锁定不是“绝对"锁定吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！