On a particular server (Windows 2012 server R2) I am having trouble creating a temp file. I get the following error everytime I try.
java.io.IOException: The system cannot find the path specified
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(Unknown Source)
etc..
The error happens everytime the following code is ran:
InputStream inputStream = portalBean.createPDF( sessionID, foCode );
Things I have tried
Changed the java.io.tmpdir variable on the fly. System.setProperty("java.io.tmpdir", "C:\\");
Added -Djava.io.tmpdir=c:\\temp to the webnetwork lax file to an unrestricted location.
I tried setting the webNetwork service to run as a specified user with rights to temp files e.g. the Administrator.
Made sure I have free disk space and I cleaned out the c:\windows\temp folder.
Made sure the tmp environment variables were set to their default values.
I also tried running the service from a command prompt which was opened with the Run As Administrator option.
And the IOException lingers still. I have another server running the same code without issue (Windows Server 2012).
Does anyone else have any Ideas of what else I can try to resolve this issue? And or any tips on how I can debug the issue more thoroughly to get a grasp of what is going on?
One tool you can use to debug this is process monitor from system internal tool kit. The step is: add a filter to only monitor your process (I think it is javaw.exe in your case), after the error happens, go through the file activities in the process monitor log, you can find how the process is finding files and which directories the process searched. If the process is searching in the wrong directory, you can find it from the log.
I just used this tool to figure out a JVM crash problem today.
Based on the description of your problem, I guess the path variable of the process is changed in the middle of your code, with another tool process explore you can view the path variable of the process, it might help.
Try and create instead a directory somewhere under your home directory:
final Path tmpdir = Paths.get(System.getProperty("user.home"), "tmp");
Files.createDirectories(tmpdir);
System.setProperty("java.io.tmpdir", tmpdir.toAbsolutePath().toString());
Then try and Files.createTempFile() in there.
Note that if Files.createDirectories() refers to an existing file which is not a directory, you'll get a FileAlreadyExistsException.
Related
We use the install4j "Update downloader with silent Version check" to periodically update our application installer.
With the introduction of the "Update downloader with silent Version check", we have noticed two problems from the Users.
Error opening media file as can be seen in the screenshot. The Media file is the file that is downloaded in the 1st Step of the updater. Screenshot below
The error log file mentions
[0:918] extracting files
[0:932] Included files: 16
[3:537] ERROR: Could not open FFFFFFFFFFFFFFFF 32 C:\Users\ttttttttt\Downloads\xxxxxxxxxx_7_xxxx_yy_zz_64Bit.exe
[128:104] emptying C:\Users\ttttttttt\AppData\Local\Temp\e4j8A6C.tmp_dir1662356615
The Users have not opened the downloaded file. Normally clickin on OK and a retry generally works.
The second problem some users are facing
[![enter image description here][2]][2]
The 2nd error mentions that the bgupdater.exe is already running. Even here, clicking on "Wiederholen" generally works and the update proceeds.
What we do not understand is that why these errors arise. A retry proceeds without errors in all cases normally.
The application uses install4j version 8 and java 1.8
[2]: https://i.stack.imgur.com/jVl3I.png
The first problem looks like anti-virus software problem where the anti-virus software detects a .exe file that is extracted to the %TEMP% directory and immediately quarantines it.
For the second problem, please locate the log file of the running bgupdater process which is located in the %TEMP% directory. Either you start the bgupdater process too frequently or it is hanging somewhere, you would need to find that out. To install a new version, all executables of the installation must be closed.
I am running TimesTen facing application in local (in eclipse IDE). URL and username and password seems to be fine. But I am getting below exception.
java.sql.SQLException: Problems with loading native library/missing methods: no ttJdbc181 in java.library.path
at com.timesten.jdbc.JdbcOdbcConnection.connect(JdbcOdbcConnection.java:2012)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:296)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:152)
at org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:319)
at org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:212)
at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:736)
at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:668)
at org.apache.tomcat.jdbc.pool.ConnectionPool.init(ConnectionPool.java:483)
at org.apache.tomcat.jdbc.pool.ConnectionPool.<init>(ConnectionPool.java:154)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.pCreatePool(DataSourceProxy.java:118)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.createPool(DataSourceProxy.java:107)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.getPool(DataSourceProxy.java:214)
I checked the bin folder of TimsTen installation directory did not see ttJdbc181.dll file Instead I found ttJdbcCS.181 in the folder. I don't know why code is looking for ttjdbc181.dll file. I have tried adding ttjdbc8,9,10,11 to class path still same issue. Any help to resolve this issue will be appreciated.
Had same stack trace.
All I had to do is to add "jdbc:timesten:client:" to my connection string. It is driver and protocol as far as my understanding goes.
My connection string looks like follows:
jdbc:timesten:client:TTC_Server=127.0.0.1;TTC_Server_DSN=myDsn;UID=user;PWD=userpasswd;TCP_PORT=9999;
This was issue on Windows. Assume same would arise for Linux.
Also please ensure you have correct CLASSPATH, Lib, Include, Path environment variables.
Windows installer usually takes care of this. On Linux you have to run ttenv.sh script from directory of your installed instance, this will set env vars as required.
i am trying run the websphere liberty profile server from the command line. I am following the steps told here : https://developer.ibm.com/wasdev/downloads/liberty-profile-using-non-eclipse-environments/
I have created the server with the name server1.
But when the extraction completes and I try to start the server using the command : server start server1
the server throws an error : CWWKE0054E: Unable to open file C:\wlp\wlp\usr\servers\server1\logs\C:\Users\Furquan\AppData\Local\Temp\\ihp_custom_batches.log.. Now I know this cant be a valid path, but I dont know where and how to change it. Please help !!
This error is related to the LOG_FILE environment variable that you have defined in your environment by some other program. To solve that, you have the following opions:
Remove LOG_FILE env variable, if it is no longer needed by your system
If you cant do that, override it via server.env file, that you can create in the wlp\usr\servers\serverName directory with the following content:
LOG_FILE=console.log
As last resort (this is not recommended, will make your installation NOT SUPPORTED and in certain installations might get overwritten by updates) - modify the server.bat command line script - in the script find the following section:
if not defined LOG_FILE (
set X_LOG_FILE=console.log
) else (
set X_LOG_FILE=!LOG_FILE!
)
And after the line set X_LOG_FILE=!LOG_FILE! just add another line that will override it with the default like this set X_LOG_FILE=console.log
In general, I'd recommend second solution (with the server.env file), as it is the most portable and will work in any environment.
I have the similar problem for IBM Support Assistant V5. After I deleted %LOG_FILE% from Environment Variables, it worked.
Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.
If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.
I.E. the following won't work any more with 1.6.0_29:
-Djava.rmi.server.codebase="file:myproject/bin/ ..."
We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?
Note: No, we do not want to start a local webserver or ftp server.
Update:
On Naming.bind this exception is thrown:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: access to class loader denied
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.
Take running in windows as an example:
Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:
grant { permission java.security.AllPermission; };
Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly.
Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.
Step 2. Start rmiregistry:
C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/
(Please note codebase must ended with "/")
Step 3. Run your server and client program.
References:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html
It looks like there is no workaround because it is a bug, so wait for the fix
See details at
https://bugzilla.redhat.com/show_bug.cgi?id=751203
Code fix
http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734
If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:
Windows:
set CLASSPATH="path_to_jarfile"
Linux (batch):
CLASSPATH="path_to_jarfile"
export CLASSPATH
Best place to do it is in some script that invokes the RMI server.
Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!
If you start the rmiregistry in the working directory of your project, it works.
So essentially working directory of your project and current directory for rmiregistry should be same.
I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:
be started in the root of the directory containing the shared classes; or
set the classpath to point to the shared classes or shared class jar; or
use a protocol other than file:// (I set up ngnix and served the jar from that).
Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.
I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &
i'm having the the post's title error when trying to write a file on a window folder , mounted on unix system. I've developed a web service which runs inside a Tomcat 6 on a linux os and need to write on a windows network folder. System administrators have mounted it on the Linux sever and have no problem to create and modify a file on it.
When i try to execute the posted code i get the following exception :
Permission denied
java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:850)
The weird thing is that it seems to be related to the File.createNewFile method on a network folder , in fact the service can write on local file system without problems, both on debug (the pc i use to develop the service) and a tomcat folder system administrators have provided me on the linux server. The file gets created but is empty and the log entry following the create method doesn't get printed. Moreover if i use a plain outputstream to create and write the file i've no problems.
I cannot find any explanation about the exception on the web. Since i'm not very experienced with java , i'd like to understand why i'm getting this error. Am i using it in the wrong way ? Is it a bug of the library ? Do i miss to pass some parameter ?
As stated , i've solved the problem using a plain outputstream, this is a question to improve my understanding of java.
FileOutputStream fos = null;
try{
log.info(String.format("file length: %s",streamAttach.length));
log.info(String.format("check File : %s",filename));
File f = new File(filename);
if(f.exists())
...
boolean done= f.createNewFile();//here comes the exception
//nothing of the following happens
if(!done)
throw new NWSException("error creating file");
log.info(String.format("file %s creato", nomeFile));
thank you in advance for any answer
I ran into this problem recently and found that java.io.File.createNewFile() actually requires the "Change Permissions" permission (you can find this entry under Security->Advanced when checking folder permissions). Without this it will create the file and then subsequently throw an IOException.
It's deceptive because you will still be able to create files on the folder when manually testing, however createNewFile() will still fail if it doesn't have this particular permission (presumably such that it can change the permissions on the file its creating).
If you are using Netapp that shares an NTFS (CIFS) style filesystem to Unix you could be experience "NFS is not allowed to change permissions on a file in an NTFS-style security volume." (TR-3490 page 16)
Options here are to change to a unix filesystem or set the cifs.ntfs_ignore_unix_security_ops flag to on for the file system which quiches the NFS permission error.
java.io.UnixFileSystem.createFileExclusively(Native Method) opens the file with the O_EXCL and 0666 umask so I would get a EACCES, which really was a NFS3RR_ACCES
open("/net/storage01-a/filer/myfile", O_RDWR|O_CREAT|O_EXCL, 0666) Err#13 EACCES
Also you can use OutputStream to create the file, that does not use O_EXCL it seemes
It definitely not Java specific problem. If this Unix folder is mapped to your windows try to open file explorer and create file in this directory. I believe that you will get permission denied too. In this case fix this problem or ask your system administrator to help you.
Good luck!