I have a rather silly question, but I haven't been able to find a solution for this:
When I try and read a file I get a "file not found error" is runtime. It compiled the file though.
I am on Linux, so I use the statement something like:
Scanner s = new Scanner(new File("home/me/java/ex.txt"));
and it gives me a runtime rror:
/home/me/javaException in thread "main" java.io.FileNotFoundException: home/me/java/ex.txt (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:137)
at java.util.Scanner.<init>(Scanner.java:653)
at test.main(test.java:14)
I tried changing every possible thing along the lines of filenames, but nothing seems to work.
Any clues as to why this is happening? where does java look for files by default?
Looks like you are missing a leading slash. Perhaps try:
Scanner s = new Scanner(new File("/home/me/java/ex.txt"));
(as to where it looks for files by default, it is where the JVM is run from for relative paths like the one you have in your question)
I think Todd is correct, but I think there's one other thing you should consider. You can reliably get the home directory from the JVM at runtime, and then you can create files objects relative to that location. It's not that much more trouble, and it's something you'll appreciate if you ever move to another computer or operating system.
File homedir = new File(System.getProperty("user.home"));
File fileToRead = new File(homedir, "java/ex.txt");
The Official Documentation is clear about Path.
Linux Syntax: /home/joe/foo
Windows Syntax: C:\home\joe\foo
Note: joe is your username for these examples.
Related
Question - Get File Version of .exe in java on Linux for some strange client.
Solution -
I used JNA library to read file version using Java. Given below code is running fine on windows platform but it is throwing below error on Linux docker image.
"Unable to load library 'version': Error loading shared library libversion.so: No such file or directory Error loading shared library libversion.so: No such file or directory Native library (linux-x86-64/libversion.so) not found in resource path..".
private String GetFileVersion(String filePath) {
File fileToCheck = new File(filePath);
short[] rtnData = new short[4];
int infoSize = Version.INSTANCE.GetFileVersionInfoSize(fileToCheck.getAbsolutePath(), null);
Pointer buffer = Kernel32.INSTANCE.LocalAlloc(WinBase.LMEM_ZEROINIT, infoSize);
try {
Version.INSTANCE.GetFileVersionInfo(fileToCheck.getAbsolutePath(), 0, infoSize, buffer);
IntByReference outputSize = new IntByReference();
PointerByReference pointer = new PointerByReference();
Version.INSTANCE.VerQueryValue(buffer, "\\", pointer, outputSize);
VerRsrc.VS_FIXEDFILEINFO fileInfoStructure = new VerRsrc.VS_FIXEDFILEINFO(pointer.getValue());
rtnData[0] = (short) (fileInfoStructure.dwFileVersionMS.longValue() >> 16);
rtnData[1] = (short) (fileInfoStructure.dwFileVersionMS.longValue() & 0xffff);
rtnData[2] = (short) (fileInfoStructure.dwFileVersionLS.longValue() >> 16);
rtnData[3] = (short) (fileInfoStructure.dwFileVersionLS.longValue() & 0xffff);
return String.format("%s.%s.%s.%s", rtnData[0], rtnData[1], rtnData[2], rtnData[3]);
} catch (Exception exception) {
return null;
} finally {
Kernel32.INSTANCE.GlobalFree(buffer);
}
}
I will start by answering the question that you asked, though I doubt it is what you actually need to know.
The types of different executable file formats are encoded in the first few bytes of the file. For example, ELF files (executables, shared libraries) are described in this Wikipedia page.
So there are a number of ways to find out what kind of executable in Java:
Write some code that reads the first few bytes and decodes the file header information, as per the format described in the Wikipedia link above.
Find an existing Java library that does this and work out how to do this. (Google for "java file magic library" and see what you can find.)
Read about the Linux file command and write some Java code to run file on each library and parse the output.
What I think you actually need to do is a bit different:
Locate the file or files in the file system that the Java is looking for: apparently libversion.so or linux-x86-64/libversion.so. (The file could well be a symlink. Follow it.)
Run file on each file to check that it is the right kind of library. They need to be 32 or 64 bit corresponding the JVM you are running, and the correct ABI and ISA for the platform.
Check that the files are where the JVM expects to find them. The JVM searches for libraries in directories listed in the "java.library.path" system property. You can (if necessary) set the path using a -Djava.library.path=... JVM option.
See "java.library.path – What is it and how to use" for more information on library loading.
(There is absolutely no need to do step 2 "from" or "in" Java.)
I think I have finally worked out what you are doing.
The Version you are using is actually coming from the package com.sun.jna.platform.win32. It is not part of the JNA library (jna.jar). I think it is actually part of jna-platform.jar. If I understand things correctly, that is the generated JNA adapter library for the Windows COM dlls.
If I have that correct, you would actually need the Windows COM native libraries compiled and built for the Linux platform to do what you are trying to do.
AFAIK, that's not possible.
So how could you make this work? Basically you need to do one of the following:
Look for an existing pure Java library for extracting the version information from a Windows ".exe" file. I don't think it is likely that you will find one.
Find the specification for the Windows ".exe" file format and write your own Java code to extract the version information. I haven't looked for the spec to see how much work it would be.
Then you rewrite the code that you added your question to use the alternative API.
The "libversion" file that I mentioned in my other answer is not relevant. It is something else. It is a red herring.
I'm creating a task plugin for Atlassian Bamboo. At some moment of task executing, I would like to create a temporary file:
File temp = File.createTempFile(fileName.toString(), null, dir);
temp.deleteOnExit();
, where:
fileName.toString() = e.g. "C:\Atlassian\bamboo-home\xml-data\build-dir\CMPT-CMPTP-JOB1\test.java"
dir = new File("temp");
When testing this locally, everything works fine - the file is created properly. However, after I deploy plugin on server and try to execute above code, I've got an IOException:
java.io.IOException: The filename, directory name, or volume label syntax is incorrect
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:1879)
What could be the reason?
Additional info: I'm pretty sure that dir.exists() .
A file name of
"C:\Atlassian\bamboo-home\xml-data\build-dir\CMPT-CMPTP-JOB1\test.java"
is valid on Windows but is invalid on Unix operating systems. You won't be able to create a (temp) file like that, either as specified as the absolute name/path or the file nor just relative to another folder.
If your OS is Windows, you still can't use a full path (starting with drive specification like "C:") to be created as a child of another folder.
You could have spaces in the beginning or the ending of your path, print your file.getAbsolutePath() in order to see the current path where java is reading.
The dir variable must be set with the full (or relative) path to the directory temp. The first arg of File.createTempFile should be the prefix of the temp file (at least three letter long. for exeample "test"). This will create a "test.tmp" in the given directory (specified by the variable dir).
Check the javadoc
You can check existence of the directory dir with dir.exists()
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.
I have a simple Servlet that needs to pass some properties files to another class.
Properties prop = new Properties();
prop.load(new FileInputStream("/home/user/config.properties"));
Above works fine.
But I can't address the right absolute path in below:
String protocol = prop.getProperty("protocol", "/home/user/protocol.properties");
String routes = prop.getProperty("routes", "/home/user/routes.properties");
MyClass message = new MyClass(protocol, routes, 0);
At the end I receive below from tomcat log:
INFO: Server startup in 3656 ms
java.io.FileNotFoundException: routes.properties (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at java.io.FileInputStream.<init>(FileInputStream.java:97)
at com.cc.verticals.Messenger.<init>(Messenger.java:134)
at com.foo.MyClass.<init>(MyClass.java:42)
at com.verticals.cc.util.VerticalUtil.setup(VerticalUtil.java:59)
at com.verticals.cc.util.VerticalUtil.main(VerticalUtil.java:259)
at com.verticals.cc.dao.VerticalDao.<init>(VerticalDao.java:24)
at com.verticals.cc.controller.VerticalController.<init>(VerticalController.java:33)
Line 42 is pointing to the constructor where routes.properties file goes in.
Messenger line 134 points to:
prop.load(new FileInputStream(routesFilename));
Any Idea how to address the properties files and send them as a String parameter? Thanks.
By the looks of it (I prefer if you post the content's of the properties files), there is a property within config.properties such that routes = routes.properties. When you call new file(routes); you get the FileNotFoundException because you are trying to open routes.properties in the current working directory where java was launched (which doesn't exist)
As a side note, you using one property file to reference another property, which is fine but a bit odd or unconventional. Further, you should stick these files in a 'resource' folder to remove absolute paths and gain portability.
Notice that prop.getProperty method cannot throw FileNotFoundException. So that exception must have been thrown earlier on prop.load();
Please make sure that you have opened the permissions on the file. Open a terminal and issue following command:
$ chmod 777 /home/user/routes.properties
$ chmod 777 /home/user/protocol.properties
It's quite possible i've misunderstood the purpose of the File dir argument in Runtime.exec(String command, String[] envp, File dir):
"The working directory of the new subprocess is specified by dir. If dir is null, the subprocess inherits the current working directory of the current process."
If I run Runtime.exec("C:/mydir/myfile.bat"); the script is executed (albeit with the wrong working dir)
however if I run Runtime.exec("myfile.bat", null, new File("C:/mydir")); i get the following error:
java.io.IOException: Cannot run program "myfile.bat" (in directory "C:\mydir"): CreateProcess error=2, The system cannot find the file specified
at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
at java.lang.Runtime.exec(Runtime.java:593)
I would assume that the dir argument sets the working directory for the new process as well as the command being executed, however maybe it just does the former. if that is the case the exception message is quite misleading.
How about
Runtime.exec("C:\mydir\myfile.bat", null, new File("C:\mydir"));
From ProcessBuilder.java
// It's much easier for us to create a high-quality error
// message than the low-level C code which found the problem.
Thats why you get a non specific exception - otherwise the JDK would need to implement exception handling similar to Spring's DataAccessException hierarchy handling OS specific error codes.
Edit: you may want to look at commons-exec
I do not know if it has something to do with it, but the \ is used to escape characters.
I always use forward slashes in Java and they are properly converted.
Otherwise I would recommend to always use \ i.e. double slashes to avoid mishaps like "C:\newfile" which would be C:-newline-ewfile.