java 权限 创建文件_Java的文件权限

java 权限 创建文件

Java has always been considered a multi-platform language - you write your code once and then you use it on almost any Operating System. Unfortunately for most Java developers, this is often taken quite literally from anyone that had no knowledge of the language, including some managers and system admins.

Java一直被认为是一种多平台语言-您编写一次代码，然后在几乎所有操作系统上使用它。 不幸的是，对于大多数Java开发人员来说，这通常是从不懂该语言的任何人，包括一些管理人员和系统管理员那里获得的。

If you had ever seen any Java code that deals with files and directories, you already know that if the programmer is not careful, the otherwise multi-platform code will simply fail when the OS is changed. But what happens if you are careful (you use File.separator instead of hardcoded "/" and "\\", you don't presume that every file path will have a ":" in it and so on)? You should not worry that moving the code from Windows to Unix will break it, right?

如果您曾经看过任何处理文件和目录的Java代码，那么您已经知道，如果程序员不小心，当更改操作系统时，否则，多平台代码将完全失败。 但是，如果小心一点会发生什么（使用File.separator而不是硬编码的“ /”和“ \\”，您不假定每个文件路径中都带有“：”，依此类推）？ 您不必担心将代码从Windows迁移到Unix会破坏代码，对吗？

Well, that's where the bad news start - technically your code might work (if the Unix admins make sure that all the input files have correct ownership and permissions) but it may turn out that the next application that should use your output files as input or the user that tries to download them via FTP cannot even read them while the same application and/or user on Windows had never had these issues. The reason for this is the different ways in which the file permissions and ownership work in Unix. The obvious solution is just to make sure that your code is properly setting the permissions if it is run in a Unix environment, so you open the java.io.File documentation to search for some methods to accomplish this...just to find out that such methods are missing there.

好的，这就是坏消息的开始-从技术上讲，您的代码可能会起作用（如果Unix管理员确保所有输入文件都具有正确的所有权和权限），但可能结果是下一个应用程序应该将您的输出文件用作输入或尝试通过FTP下载它们的用户甚至无法读取它们，而Windows上的同一应用程序和/或用户从未遇到过这些问题。 原因是在Unix中文件权限和所有权的工作方式不同。 显而易见的解决方案是确保在Unix环境中运行时，代码可以正确设置权限，因此您打开java.io.File文档以搜索实现此目的的一些方法...只是为了找出答案。那里缺少这种方法。

This article is showing the few alternatives that exist in the current versions of Java and what is expected in the future ones. All the examples will be showing the invocation of the command chmod which changes the permissions of a file on a Unix system.

本文展示了Java当前版本中存在的几种替代方案以及未来的替代方案。 所有示例都将显示chmod命令的调用，该命令将更改Unix系统上文件的权限。

1.系统调用 (1. System Calls)

The Unix systems already have their own system calls for changing the permissions and the ownership of a file and Java have a more than adequate wrapper that allows you to invoke them. So you can always just do it:

Unix系统已经有自己的系统调用来更改权限和文件所有权，而Java具有足够的包装器，可以用来调用它们。 因此，您始终可以这样做：

String fileName = "/path/to/file", 
Process proc = Runtime.getRuntime().exec("chmod 755 " + fileName);

- It has performance issues because of the invocation of the external method.

-由于调用了外部方法，因此存在性能问题。

- On some systems, the chmod command might not be readily available for invocation from Java and you might need to specify a full path to it. This is easily solvable with reading it from a configuration file of course but still, it is an additional thing that you should not forget.

-在某些系统上，chmod命令可能不容易从Java调用，因此您可能需要指定它的完整路径。 通过从配置文件中读取它很容易解决，但仍然是您不应该忘记的另一件事。

2. JNA (2. JNA)

But what if a similar approach can be used without the problems that were listed above? As long as your JVM version is 1.4 or higher, you can use the JNA library to invoke the underlying OS call:

但是，如果可以使用类似的方法而没有上面列出的问题，该怎么办？ 只要您的JVM版本是1.4或更高版本，就可以使用JNA库来调用基础的OS调用：

import com.sun.jna.Library;
import com.sun.jna.Native;
 
public class ChmodTest {
    private static LinkedOSLibrary linkedLibrary = 
        (LinkedOSLibrary ) Native.loadLibrary("c", LinkedOSLibrary.class);
 
    public static void main(String[] args) {
        linkedLibrary.chmod("/path/to/file", 0755);
    }
}
 
interface LinkedOSLibrary extends Library {
    public int chmod(String path, int mode);
}

3. JTux (3. JTux)

Another library that can be used is called JTux (Java to Unix). It provides a wrapper that allows you to invoke almost any Unix command:

可以使用的另一个库称为JTux（Java到Unix）。 它提供了一个包装器，使您可以调用几乎所有的Unix命令：

UFile.chmod("/path/to/file/", 0775);

4.朝正确方向迈出的第一步-Java 6和java.io.File更改 (4. The first steps in the right direction - Java 6 and the java.io.File changes)

The three options that we saw until now were all relying on the OS calls which was making them hard to be used if the program need to run on Unix and on Windows (or at least the OS had to be checked every time before invoking them as these commands do not exists on a Windows server). When Sun published the first information about Java 6 a few years ago, we saw the first steps taken by Java to start closing the gap between what the language is expected to be doing and what it actually does. And even if the three added methods to the java.io.File class (setReadable, setWriteable and setExecutable) do not allow the full range of chmod to be covered, they at least allow the major properties of the files to be set.

到目前为止，我们看到的三个选项都依赖于OS调用，如果程序需要在Unix和Windows上运行（或者至少必须在每次调用OS之前都要检查OS），这使得它们很难使用。 Windows服务器上不存在这些命令）。 Sun几年前发布有关Java 6的第一份信息时，我们看到Java采取的第一步是开始弥合语言的预期功能和实际功能之间的差距。 并且即使向java.io.File类添加的三个方法（setReadable，setWriteable和setExecutable）不允许覆盖整个chmod范围，它们至少也允许设置文件的主要属性。

5. NIO.2和Java 7 (5. NIO.2 and Java 7)

In 2003, Sun finally decided to give in to the pressure and to start working on a JSR which would allow the gap in how the file is handled to be closed. This JSR received the number 203 and the early drafts were discussed in 2007. During JavaOne 2009, in June, some of the talks for the Java 7 release were concerning the JSR 203 and its implementation as part of the standard J2SE 7. More details will emerge for the usage of this new library in the future but it starts to look like good news for Java.

在2003年，Sun最终决定屈服于压力，并开始着手开发JSR，这将使文件处理方面的空白得以弥合。 该JSR收到编号203，并在2007年讨论了早期的草案。在JavaOne 2009中，6月，有关Java 7发行版的一些讨论涉及JSR 203及其作为标准J2SE 7的一部分的实现。将来会出现使用此新库的情况，但对于Java来说，它似乎已成为好消息。

6.失落的图书馆 (6. The lost library)

I had an intention to finish the article with the good news for Java 7 but there is one more library that had not been mentioned. Once upon a time, a company called Xenon Soft created a library called Javaunix which was similar in some ways to the JTux library. This is the library that I had been using for years but these days the site is no more available and the library seems to have disappeared. I will be happy to hear some news about it, even if Java 7 solves all the issues - there will always be old applications that cannot be upgraded just yet.

我本打算以Java 7的好消息来结束本文，但是还有一个未提及的库。 曾几何时，一家名为Xenon Soft的公司创建了一个名为Javaunix的库，该库在某些方面类似于JTux库。 这是我使用多年的图书馆，但如今这些站点不再可用，图书馆似乎已经消失了。 即使Java 7解决了所有问题，我也会很高兴听到一些有关它的消息-总会有一些旧的应用程序无法升级。

Resources

资源资源

More information for the libraries and projects above can be found on the following links:

有关上述库和项目的更多信息，请参见以下链接：

JNA: The JNA library  

JNA： JNA库

JTux:http://www.basepath.com/aup/jtux/

JTux： http ： //www.basepath.com/au p / jtux /

Java 6 Javadoc:java.io.File

Java 6 Javadoc： java.io.File

NIO.2: JSR 203 and The Java NIO.2 File System in JDK 7

NIO.2： JDK 7中的 JSR 203和Java NIO.2文件系统

The lost library: The only survived note for it

失落的图书馆： 唯一幸存的笔记

翻译自: https://www.experts-exchange.com/articles/1498/File-permissions-with-Java.html

java 权限 创建文件