Develop Reference

Java Changing Linux File Permission Sometimes Does not Work

I am working on a task, which is changing the file's permission to 640 after our code exports the file to our Linux server. The same code works in our Dev server, but in our Uat server, sometimes the permission is changed to 640 successfully, sometimes the permission can not be changed, is still the default 600.
I checked the SystemOut.log, no any error for this.
My related Java code is like below:
private void exportXXXFiles() {
......
//Settings for the access permissions of the exported files
Set<PosixFilePermission> filePerms = new HashSet<PosixFilePermission>();
filePerms.add(PosixFilePermission.OWNER_READ);
filePerms.add(PosixFilePermission.OWNER_WRITE);
filePerms.add(PosixFilePermission.GROUP_READ);
try {
Path localFilePath = ......;
Files.setPosixFilePermissions(localFilePath, filePerms);
......
} catch (IOException e) {
e.printStackTrace();
}
}
I am confused why the same code works in our Dev server but not stable in our Uat server, where sometimes it works sometimes it does not work. I assume that is the environment issue, but I have no idea what the exact issue is. Who can give me some suggestions?
Thanks!

There are a few reason why changing permissions might not work. These include:
The application doesn't have permission to change permissions. With classic UNIX / Linux, you need to be the file owner or root to change an file's permissions. Then there are ACLs.
The file system might be read-only, or mounted read only.
The file system type might not support the combination of permissions you are trying to use. For example, FAT did not support execute permissions, and NTFS permissions work a bit differently. Unfortunately, when you mount a "foreign" file system type on Linux, the OS doesn't provide a way to direcrly manipulate the file system's native permissions.
It is possible that what you are trying to do is blocked by SE Linux or AppArmor or similar.
Now, some of these may result in a Java exception when you attempt to change the permission. But that is up to the OS and the file system drivers. Java can only throw an exception if the OS tells Java that the permission change attempt failed, and it can only report / interpret the reason (the errno) returned by the chmod syscall.

How to enumerate connected USB storage devices Ubuntu Java

I have an application, mostly in Java' that controls an airborne infrared camera via a webpage GUI (served by the Ubuntu machine) which starts running automatically when the computer is powered up and towards the end of the boot. The application runs as a user, not root, even though the user is not logged in.
After a great many images are collected the data need to be archived by using rsync to a folder on the operator's USB drive. I need to have the USB drive mounted and know its name tag. The computer is headless and the operator, who is on the aircraft, cannot be expected to know Linux in any case.
On an Ubuntu I see that logged in and running the xfce4 GUI, and only then, the drives are listed in /media/user-name/drive-tag (I note that /media/username is owned by root but the folder named for the drive is owned by the user.) and are shown in /etc/mtab :
/dev/sdd1 /media/programmer/DATA-02-2TB vfat rw,nosuid,nodev,uid=1001,gid=1001,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2 0 0
How can I, through Java or through a combination of Java and bash, detect and mount a USB storage device?
If that's not possible do I need to ask the user, through the GUI, to enter the device tag or name, e.g., 'DATA-02-2TB' and then create the mount point and mount the USB drive via a script using the information above?

First install usbmount, a Ubuntu tool.
sudo apt-get update
sudo apt-get install usbmount
Then edit the /etc/usbmount/usbmount.conf file:
sudo sed -i 's/MOUNTOPTIONS="/MOUNTOPTIONS="user,umask=000,/' /etc/usbmount/usbmount.conf
These steps are described at Serverfault. Note that only a subset of drive formats is supported including the ubiquitous VFAT.
With this in place USB external drives and thumb drives will mount in /media as /media/usb0 through /media/usb7 and will be listed in /etc/mtab.
/dev/sdc1 /media/usb0 vfat rw,noexec,nosuid,nodev,sync,noatime,nodiratime,umask=000 0 0
I've tested this on my 14.04 machine. Now if I could only get the drive label.
Edit: The sync option does not work well with flash drives. Read the /etc/usbmount/usbmount.conf file for details and remove "sync" from the appropriate line in that file. A full backup made with sync option ran for over an hour before I cancelled it but took only about 5 minutes with sync removed. Note the comment about using pumount to unmount the non-synched drive.
public static ArrayList<String> usbDriveList() throws FileNotFoundException {
final String MTB_ADDRESS = "/etc/mtab";
final String TARGET = "^/media/usb[0-7]$"; // REGEX
final File file = new File(MTB_ADDRESS);
final ArrayList<String> driveList = new ArrayList<String>();
try (Scanner in = new Scanner(file)) {
while (in.hasNext()) {
final String[] splitLine = in.nextLine().split(" ");
if (splitLine[1].matches(TARGET)) {
driveList.add(splitLine[1]); // got it!
}
}
} catch (final FileNotFoundException e) {
throw new FileNotFoundException();
}
return driveList;
}

exec not working with java 1.7.21, but in netbeans works fine

I made a little program and it worked fine, but now. First, it mux the xml chapter file in the mkv file, so we get a muxed mkv file. Some day ago I updated java to 1.7.21 and I think this is the problem why it is not working now. It's a little strange, but when I run in netbeans everything is fine, but when I build and I run the .jar file, it is not working. It create the xml file, but not mux in the mkv file (and because not muxed not delete the xml file). Here is the code: (filename=xml file path; mkv=mkv file path)
public void muxing() {
try {
Runtime rt = Runtime.getRuntime();
Process p = rt.exec("c:\\Program Files\\MKVtoolnix\\mkvpropedit.exe --chapters \""+filename+"\" \""+mkv+"\"");
if (p.waitFor()==0) {
File xmlfile=new File(filename);
xmlfile.delete();
}
}
catch(Exception e) {
System.out.println(e.getMessage());
}
}
The program worked with java 1.6 and I think with 1.7.17 too. Win7 32bit. Sorry for my bad English.

Oracle has made breaking changes to Runtime.exec() in Java 7 update 21 (and 6 update 45).
If the program name contains spaces, you need to specify command and arguments in an array:
Process p = Runtime.getRuntime().exec(new String[] {
"C:\\Program Files\\MKVtoolnix\\mkvpropedit.exe",
"--chapters", "\""+filename+"\"", "\""+mkv+"\""});
Another option is to use java.lang.ProcessBuilder:
Process p = new ProcessBuilder("C:\\Program Files\\MKVtoolnix\\mkvpropedit.exe",
"--chapters", "\""+filename+"\"", "\""+mkv+"\"").start();
As stated by Oracle:
Applications that need to launch programs with spaces in the program name should consider using the variants of Runtime.exec that allow the command and arguments to be specified in an array.
Alternatively, the preferred way to create operating systems processes since JDK 5.0 is using java.lang.ProcessBuilder. The ProcessBuilder class has a much more complete API for setting the environment, working directory and redirecting streams for the process.

JSmooth generated exe does not show Splash Screen

I wrap my Java Swing application as an exe using Jsmooth but I can see no way to take advantage of Java 6 splash screen option. I have the following manifest file:
Manifest-Version: 1.0
SplashScreen-Image: resources/LOADLOGO.png
Main-Class: se.bookingapp.UI.MainFrame
The splash screen appears if I simply click on the jar file of the application. However, the JSmooth generated exe form of the jar file does not show the splash screen somehow. Does anyone know why?

Yesterday I've finished to develop my java application and I had the same issue. If I double click the .jar file or I execute in a command line splash screen works perfectly, but when I execute the wrapped file it doesn't. Seems just JSmooth doesn't support this feature.
However I made a little trick to have a wrapped .exe and splash screen working at the same time. I made a little application called ApplicationLoader.jar that consists in a single main class that execute java -jar "Application.jar" in a command line. Here is the complete code:
public class ApplicationLoader {
/**
* #param args the command line arguments
*/
public static void main(String[] args) {
/* First I check if the first parameter is not null and it's not an empty string */
if(args[0] != null && !args[0].trim().isEmpty()){
/* Then I use java.util.regex package to validate the parameter is a .jar file */
Pattern pattern = Pattern.compile(".*jar");
Matcher matcher = pattern.matcher(args[0]);
if(matcher.matches()){
/* Finally I define the command line like: java -jar "Application.jar" */
String command = "java -jar \"" + args[0] + "\"";
try {
Runtime r = Runtime.getRuntime();
ProcessBuilder pb = new ProcessBuilder("cmd.exe", "/c", command);
Process p = pb.start();
p.waitFor();
} catch (IOException | InterruptedException ex) {
JOptionPane.showMessageDialog(null, ex.getMessage(), "Error executing: "+command, JOptionPane.ERROR_MESSAGE);
}
} else {
JOptionPane.showMessageDialog(null, "The argument is not a .jar file!!");
}
} else {
JOptionPane.showMessageDialog(null, "There's not a valid argument!");
}
}
}
I have this folder structure for my application:
MyApp
+-- bin
| +-- MyApp.jar
| +-- ApplicationLoader.jar
+-- MyApp.exe
So in JSmoot I changed the classpath to ApplicationLoader.jar and add the relative location to my application in Application Arguments section like this:
And that's it. I know this is not the best option but is a workaround.
However there's a little problem:
Since ApplicationLoader.jar calls a cmd.exe then the wrapped .exe and your application will execute in two different processes.
This implies that if you have to kill .exe process for some reason (unexpected crash or something), your java application still working as a java.exe process. So in that case you must kill MyApp.exe and java.exe processes. Actually if you just kill java.exe process then MyApp.exe process will finish execution by itself.
If you keep this in mind and you can live with that I think this option is quite simple and useful.
I hope this be helpful to anybody looking for a workaround to this issue.

Does it work when you execute the jar file? Open it with WinRar for example, and check if the manifest is into META-INF folder, and LOADLOGO.png is in the right folder too.
After doing that, it should work. It works for me. Nothing wrong in your manifest.

Change permission of a created file so only the current user can read it

I need to set the permission to read a file to a specific user of the operating system, how can I do this in Java?
Edit:
The file will be created with permissions just to the user running the application, than it needs to set read permission to a single user, other users will not have the permissions to read the file.

Use the methods setExecutable, setReadable, and setWritable in java.io.File. You can use these to change any permission bit of a file you own. Direct link: http://download.oracle.com/javase/6/docs/api/java/io/File.html#setReadable%28boolean%29.
Testing this on MacOSX revels that only the user read value is changed. When program
import java.io.File;
public class Test
{
public static void main(String[] args)
{
File f = new File("test.txt");
f.setReadable(true);
}
}
the folloiwng happens.
$ touch test.txt
$ chmod 000 test.txt
$ javac Test.java
$ java Test
$ ls -l test.txt
-r-------- 1 morrison staff 0 Jun 7 13:28 test.txt

If you're targetting Windows Vista/7, build your JAR as EXE and embed a manifest requesting for Admin rights.
If it's just an I/O problem, use the default File methods setReadable, setWritable, setExecutable :)

In regards to making the permissions for a single user, start with using ncmathsadist's code to add read permissions, then change the owner of the file to whoever needs access.
I found in the Ant source code they use for the change-owner task. For unix this can be found in the Ant source tree at org/apache/tools/ant/taskdefs/optional/unix/Chown.java. You might be able to include this and use it as an API call to change the user programmatically.

if you want to change file permissions on old Java versions like Java 5, you can use this:
Runtime.getRuntime().exec("chmod 000 " + PATH + fileName);
on windows you'll have to replace chmod with the appropriate CACLS.exe command syntax