File permissions with 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.

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?

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.

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.

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:

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

Select all Open in new window

Of course, this approach has its problems:
- 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.

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:

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);
                      }
                      

Select all Open in new window

Of course this example is very basic and if you are interested to see more about this library, you can check the resources at the bottom of the article.

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:

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

Select all Open in new window

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.

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.

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.

Resources
More information for the libraries and projects above can be found on the following links:
JNA: The JNA library  
JTux:http://www.basepath.com/aup/jtux/
Java 6 Javadoc:java.io.File
NIO.2: JSR 203 and The Java NIO.2 File System in JDK 7
The lost library: The only survived note for it