Google Web Toolkit (GWT) generates huge number of temporary files in the temp (C:\Users\User01\AppData\Local\Temp) directory.
Example of a file path:
C:\Users\User01\AppData\Local\Temp\gwt-codeserver-1101830889369654349.tmp\com.company01.web.builder.BuildingsWeb\compile-2\gen\com\company01\web\theme\custom_pluto123\client\base\progressbar\Css3ProgressBarAppearance_Css3ProgressBarTemplate_render_SafeHtml__SafeHtml_text__Css3ProgressBarStyles_style__SafeStyles_wrapStyles__SafeStyles_progressBarStyles__SafeStyles_progressTextStyles__SafeStyles_widthStyles___SafeHtmlTemplatesImpl.java
The above file path contains 437 characters.
When I tried to remove this type of files from Windows Explorer, it got crashed. Also I've tried to remove or rename it from command prompt it says The filename or extension is too long.
Finally I deleted by running custom java program.
Now, my question is why Windows couldn't able to remove it? If its not supported by OS, how java removes it?
Note:
I tried all of the above commands/actions with proper UAC (Run as administrator) in Windows 7 Ultimate and the File System was NTFS
Windows had an limitation of 260 characters (=MAX_PATH) but now also allows to create paths with up to 32,767 characters through the Unicode version of its API.
Windows Explorer sadly cannot handle long paths.
Java seems to use the Unicode API and therefore can create and remove long paths.
Resources:
https://support.microsoft.com/en-us/kb/320081
https://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
Related
Noticed an odd behavior that started after moving from Java 7 to Java 8 (HotSpot 64-Bit Server) on Red Hat Linux. The problem happens for one particular user, whose jobs typically run in batch and who cannot log on at a signon prompt. Each time a command such as "java -jar hello.jar" is run by this user, a 32 KB binary file with a numeric filename (such as 18362 or 24339) is created in the current directory.
The first several readable phrases from one of the numeric files look like the following:
8J0sun.rt._sync_Inflations8J0sun.rt._sync_Deflations#J8sun.rt._sync_ContendedLockAttempts8J0sun.rt._sync_FutileWakeups0J(sun.rt._sync_Parks#J8sun.rt._sync_EmptyNotifications8J0sun.rt._sync_Notifications8J0sun.rt._sync_SlowEnter8J0sun.rt._sync_SlowExit8J0sun.rt._sync_SlowNotify8J0sun.rt._sync_SlowNotifyAll8J0sun.rt._sync_FailedSpins#J8sun.rt._sync_SuccessfulSpins8J0sun.rt._sync_PrivateA8J0sun.rt._sync_PrivateB#J8sun.rt._sync_MonInCirculation8J0sun.rt._sync_MonScavenged8J0sun.rt._sync_MonExtant
We now have over 6,000 32 KB files with a numeric filename in the directory from which the "java" command is launched.
This is on a production server. We don't have the same problem on a development server. However, the user in question has the ability to log onto the development server (say with putty) -- whereas the user can't do that on the production server.
I'd like to know what causes the creation of all these files and how to prevent it.
Searching on a couple of the symbols in the "readable" line seems to point to hsperfdata artifacts; see this Github hsperfdata parser project. They are very likely safe to remove after java exits.
Note: If these are hsperfdata artifacts, the numbers are process identifiers. You might have these lying around on the development system in the usual temporary directories.
(Original hypothesis that the leftover files might be class file artifacts extracted from the JAR file removed.)
A user reported the following error trying to start an application via WebStart on Windows 7:
Could not load file/URL specified: C:\Users\Höfn\AppData...
The Windows locale is Iceland and the 'Language for non-Unicode programs' setting is Icelandic. Note the Windows username is supposed to be "Höfn", but the "ö" character looks corrupted in the error message so it seems the path can not contain unicode characters.
The application worked fine prior to the latest Java update.
I tried deleting the Java cache but the problem persisted.
I solved the problem (temporarily) by uninstalling the latest Java update and installing JRE 7 update 60.
I figured more people would run into this problem and require a temporary solution.
This problem starts with Java 7u65 as it is present on all later Java versions including 7u67 and 8u11. I submitted bug report.
While we wait for Oracle to fix this, here are three things we can do:
Workaround one: (only works for Java < 7u65)
Go to Control Panel -> Regional and Language Options -> Administrative (Advanced) -> Language for non-Unicode programs
Set "Current language for non-Unicode programs" to any language that uses Unicode letters.
Workaround two: (works for all - Change Java temporary path of user)
Create new directory for example C:\TempJava\ASCII_USERNAME (without Unicode letters inside path name)
As changing Java temp path inside Windows7 is disabled in Java Control Panel, there is workaround:
Open file %SYSTEMDRIVE%\Users\%USERNAME%\AppData\LocalLow\Sun\Java\Deployment\deployment.properties
Add line: deployment.user.cachedir=C:\TempJava\ASCII_USERNAME
Save and try to run JNLP again
Workaround three: (works for all)
Create user with account name in ascii text (without multi-byte letters)
Start JNLP from that account
I have installed the JGR package but when I try to invoke it, the error says
__Non-existent directory specified in --libpath=__. Maybe because of a white space in the path variable, __\Users\Scholars Psy\Documents\R\win-library\3.0__ which cannot be read?
I am running a 64-bit Windows 7 OS. I have installed both 32-bit and 64-bit versions of Java.
I tried installing JGR using the .exe file from JGR website, which is also not working.
My ultimate need is to use Deducer, which seems to be working well from inside JGR only.
The problem is the space in the Scholars Psy folder name.
Specify directory with your command line argument.
example:
set R_HOME=C:\PROGRA~1\R\R-30~1.1
set R_LIBS=C:\Program Files\R\R-3.0.1\library
set R_LIBS_USER=C:\Program Files\R\R-3.0.1\library
jgr-1_62-x64.exe --rhome=C:\PROGRA~1\R\R-30~1.1 --libpath=C:\PROGRA~1\R\R-30~1.1\library
I have problem with this annoying ^M, while exporting some data, writing it to a CSV file to be downloaded. I did some research and found out that if the file you are reading comes from a Windows system this issue happens (Windows uses CR (i.e. ^M)/LF pair to indicate the end of a line, while UNIX uses only a LF).
Now can anyone offer me a solution to overcome this problem (like eliminating or replacing ^M ) before putting it to the writer (writer.write(columnToBeInserted);)
You could use unix2dos and dos2unix to convert UNIX and Windows files respectively. Both are available on *nix and Windows platforms. Read more.
Links for Windows
Dos2Unix
Unix2Dos
Also see How to convert files from Dos to Unix in java
As you read each line do
line.replaceAll("\\p{Cntrl}", "");
Or use a tool to do it for you
in linux/unix environment there is a utilities called dos2unix and unix2dos which converts the files from windows to linux format and vise versa .
on windows check this link and download the utility whch will convert from windows to linux format http://www.sg-chem.net/u2win/
I am using imagemagick in my application. Our development machine is Windows and live server is linux. Now, in online it is working fine online. But not in development machine. I downloaded and installed Imagemagick latest release for Windows and when i try the below command in DOS-prompt, it is working fine.
convert -sample 100x100 D:\test.jpg D:\test-cropped.jpg
But when i run the same as command-line in Java program, it is not working and not giving any error too.
My code is :
Runtime.getRuntime().exec("convert -sample 250x150 "+pathName+digest+".jpg "+pathName+digest+"_thumb.jpg");
Any help is appareciated.
convert.exe is available in ImageMagick installation directory. So you need to add ImageMagick installation directory in environment variable path.
Another option is to provide complete path of convert.exe as :
Runtime.getRuntime().exec("C:\\program files\\ImageMagick\\convert -sample 250x150 "+pathName+digest+".jpg "+pathName+digest+"_thumb.jpg");
try
execute convert using the absolute path
quote your parameter input file and output file, in case they contain space
I suspect the problem is spaces in pathnames, but the solution is NOT to use escapes or quotes. The exec(String) method splits the string into "arguments" in a completely naive fashion by looking for white-space. It pays no attention whatsoever to quoting, etcetera. Instead, you will end up with command names and arguments that have quote characters, etcetera embedded in them.
The solution is to use the overload of exec that takes a String[], and do the argument splitting yourself; e.g.
Runtime.getRuntime().exec(new String[]{
"convert", // or "D:\\Program Files (x86)\\ImageMagick-6.8.0-Q16\\convert\\"
"-sample",
"250x150",
pathName + digest + ".jpg",
pathName + digest + "_thumb.jpg"
});
The other thing you could do is to capture and print any output that is written to the processes stdout and stderr.
In my case, the problem I was facing that from java compare command was working fine using Runtime.getRuntime().exec(), but when using convert, it was not working and returning me exit value as 4.
Compare execution returns exit value 0, telling that it is successfully executed.
I have system path updated with the ImageMagic's installation directory, still it was not picking 'convert' exe file. So, I started giving complete path of the convert.exe file instead of only writing only convert
e.g:
Runtime.getRuntime().exec("C:/Program files/ImageMagic......../convert.exe myImage1 -draw .... myImage2") and it worked fine this time.
Some how system was not able to pick the convert application and giving full path sorted it out. May be this solution would help someone facing same type of issue.