We Keep Coding

Play framework Windows v's Linux file path

I have developed a Play framework application on my windows PC and then transferred it onto my Linux box, I'm uploading a video and a photo to the server, this upload process works perfectly on my Windows PC, but doesn't work on the Linux box.
code I'm using in windows:
String root = Play.application().path().toString();
String globalFolderPath = root + "/public/globalUploadFolder/";
File globalFolder = new File(globalFolderPath);
Code I tried in Linux as well as the above code:
String globalFolderPath = "../../public/globalUploadFolder/";
File globalFolder = new File(globalFolderPath);
Is there a something I have to do regarding file paths differently on the Linux box, could it be a permission issue?
I'm lost as to why this is happening.

The problem was solved by using File.separator

Java ImageIO.read causing OSX to hang

I'm having to do some bits with reading in an image on Mac OSX, however it seems to hang when calling ImageIO.read ( File ). No stack trace seems to appear either, it literally just hangs. Was wondering if anyone else had experienced this problem?
I've been successful in writing an image, just seems to be a problem with reading. Working with .png files.
OSX 10.9.2
Java 1.7.40

The solution I found in the end was to do the following on the mac
File scrFile = ((TakesScreenshot)seleniumCommonHandler.getCurrentSeleniumDriver())
.getScreenshotAs(OutputType.FILE);
BufferedImage img = ImageIO.read( scrFile );
For some reason the ImageIO no matter what I tried could not read the image directly from the file system. By using this approach I managed to get around the issue.

Using nsis to package application installer and .wav file does not play because of a path on Windows containing a space --> Program%20Files

I'm running into an issue that involves an audioInputStream, a resource folder, and nsis for a Windows installation. I'm working on an app (in Linux) that performs a desktop notification when an event occurs and everything works except for the .wav file that is supposed to play when the notification pops up. I have tested the app on a 64 bit Windows machine without installing it via nsis and it works perfectly. I received an error message indicating:
07/08/13 12:17:26 ERROR [Thread-2] (DesktopNotifierMessageAlertHandler.java:73) com.alcatel.proserv.e911.desktopNotifierMessaging.desktopNotifierMessageHandler.DesktopNotifierMessageAlertHandler - Error: java.io.FileNotFoundException: C:\Program%20Files\Alcatel-Lucent\E911DesktopNotifier\classes\audio\siren.wav (Le chemin d'accès spécifié est introuvable)
I'm working in Netbeans and using maven to build. Here is a code snippet of how I'm loading the path:
String filename = this.getClass().getResource("/audio/siren.wav").getPath();
AudioInputStream audioInputStream = null;
try{
audioInputStream = AudioSystem.getAudioInputStream(new File(filename).getAbsoluteFile());
Clip clip = null;
clip = AudioSystem.getClip();
clip.open(audioInputStream);
clip.start();
}
...
I found this blog detailing how to fix an extremely similar issue:
http://braintwitter.blogspot.ro/2013/03/url-encoding-issue-with-tomcat.html
but it didn't work out with the audioInputStream I'm working with.
I know it's a problem with the space in "Program Files" which is where I have to set up the installation to occur because when I changed the InstallDir value in the setup.nsi script from $PROGRAMFILES64 to $WINDIR, it worked perfectly.
Does anyone have any suggestions for how I can modify my code to work properly since the space in Program Files is causing an encoding issue?

getResource() returns a URL, and it has URL encoding applied here. You have two options. You can convert to a URI:
String filename = this.getClass().getResource("/audio/siren.wav").toURI().getPath();
Or you can use URLDecoder to decode the path before passing it along to your AudioInputStream:
String filename = this.getClass().getResource("/audio/siren.wav").getPath();
filename = URLDecoder.decode(filename, "utf-8");
See the blurb at the end of the intro section for java.net.URL.

so I know this is pretty old thread, but anyone reading this, think twice, as the nsis packager creates this malware as scanned on virus total on a pc that's been run with malwarebytes, avira, roguekiller, hitman pro and stinger.
Antiy-AVL - Trojan/Generic.ASMalwS.3506C16, Avast-Win64:Malware-gen, AVG - Win64:Malware-gen, Cyren - W64/Tedy.B.gen!Eldorado, Jiangmin -Trojan.PSW.Python.fv, Zillya -Trojan.Disco.Script.653

Access denied when trying to execute a .exe in %AppData%

I'm trying to use RemoveDrive.exe, found here, in my Java application. I have it in my JAR, and I'm extracting it to a temporary file using the following code, however when I try to run it I get an IOException which says CreateProcess error=5, Access is denied. The program doesn't normally need admin priviledges though. Any ideas on what could be causing the issue?
File RDexe = File.createTempFile("rmvd", ".exe");
InputStream exesrc = (InputStream) GraphicUI.class.getResource("RemoveDrive.exe").openStream();
FileOutputStream out = new FileOutputStream(RDexe);
byte[] temp = new byte[1024];
int rc;
while((rc = exesrc.read(temp)) > 0)
out.write(temp, 0, rc);
exesrc.close();
out.close();
RDexe.deleteOnExit();
// run executable
Runtime runtime = Runtime.getRuntime();
System.out.println(RDexe.getPath() + " " + "F:\\" + " -b -s");
Process proc = runtime.exec(RDexe.getPath() + " " + "F:\\" + " -b");
InputStream is = proc.getInputStream();
BufferedReader reader = new BufferedReader(new InputStreamReader(is));
String line; boolean ejected = false;
while((line = reader.readLine()) != null)
if(line.equalsIgnoreCase("failed")) ejected = false;
else if(line.equalsIgnoreCase("success")) ejected = true;
reader.close();
is.close();
UPDATE: If I enable the built-in Administrator account (net user administrator /active:yes), everything works fine from there. However if I right click and run as administrator in my standard account, I still get the error and UAC doesn't even ask for permission.
EDIT: Seeing as though the bounty is nearly finished, please see my SuperUser question which has helped me solve this problem... I'll be awarding the bounty and accepting an answer soon.

This may not be the problem in your situation, but some anti-virus programs will prevent executables or scripts inside temporary folders from being run. Instead of creating a temporary file, try putting it in the user directory:
File rdExe = new File(System.getProperty("user.home") + "/.yourProgramName/rmvd.exe");
rdExe.getParentFile().mkdirs();

just a heads up on another way to run files, have you thought of using the java Desktop object? : http://docs.oracle.com/javase/6/docs/api/java/awt/Desktop.html
i've found it useful when needing to run programs through my java program. something like this could work for you:
Desktop.getDesktop().open(new File("enter path and name of the file"));
hope you find it useful

I am not JAVA user but isn't it 32 vs. 64 bit issue ?
On 64 bit Windows error code 5 usually means that executable is not 64 bit compatible. Sometimes this is the case even when executable need to access only some (older win) system directory which does not exist anymore. To prove this try to use your executable in command line. if you can manage to get it work there than it is different issue. If not find executable for your OS.
Another possibility is that the file has to be physically present on some drive.
You wrote that you has it as temporary. Not shore what it means for JAVA. If it only copy it to some file and delete after use than its OK but if it is only in memory somewhere than that could be problem if executable need access to itself. To prove this just copy the file to some known location and then run it from there (in JAVA). if it works than you will need to do something about it (copy and delete executable from JAVA before and after execution to physical disk medium or whatever)
Another possibility is that error code 5 comes from JAVA environment an not from OS
In that case I have not a clue what it means (not JAVA user)

Seeing as though it has only been touched on here, I will say that the issue was related to permissions in Windows, and is not anything to do with Java.
As stated in the SuperUser question I've linked to in my original question, I found that my usual account did not have ownership of that folder for some unknown reason - so nothing could be executed; it wasn't just the temporary file I had created in Java.
Even though I am an administrator, in order to take ownership of the folder I had to enable the Built-In administrator account and grant myself ownership. Since I did that, it has all worked as expected.
Thanks to all for their efforts, I will award the bounty to the answer that was most detailed and put me on the right tracks.

What version of Windows are you running? Microsoft significantly tightened the restrictions around executing programs in Windows 7. My guess is that it the OS won't allow you to fork something that wasn't authenticated at the time your program was launched. I'd try running it on Windows 2000 or XP and see if you have the same issues.

How can I filter out the "My Computer"-option in a SWT DirectoryDialog?

in our Eclipse RCP application running on Windows XP we use a DirectoryDialog, in which the user should... ahmm... choose a directory! :D
The problem is: If the user selects the "My Computer"-option (in German Windows "Arbeitsplatz") the Dialog returns null.
The DirectoryDialog provides a method setFilterPath(String path) in which I put the File.pathSeparatorChar (to remain OS-independant).
My suggestion was that if there has to be a file separator in the directory the "My Computer"-option would be ignored cause it is null - for example the "OK"-button would be greyed out or sth. like that... but it is also valid to klick "OK".
Any suggestions from your side? :D
Thanks in advance!
Alex

My Computer is not a directory, so I think it's fine for the OK button to be gray.