I have code that renames a file and then immediately attempts to open it.
On Windows XP this sometimes (but rarely) throws a FileNotFoundException.
The return value from renameTo is true.
Is this a known issue? Perhaps there can be a delay in the filesystem after a rename succeeds before the file actually appears?
Thanks
I have the same problem on Linux, moving files within a CIFS filesystem. The equivalent method Files.move(java.io.File, java.io.File) from the Google Guava library seems to not have this problem. What makes Guava better is that it explicitly copies the file from the source to the destination byte by byte if renameTo() doesn't return true. When I started writing this answer I didn't know that Guava delegated to File.renameTo() first, but still: no problems with Guava.
Related
Every few days, I get a SocketException, too many files open. I tracked the issue to a temporary pdf file that is being used during a certain process. The process passes a name of a temporary file that the library creates. At some point, the library opens an input stream but doesn't close it. Given that my code only has the name of the file, is there any way for me to close the stream?
Details:
Java Web App running in Tomcat6
The best approach is to request a version of this library with this bug fixed.
If this is not possible, get the sources, fix the bug yourself.
If you can't (only a binary jar file), try a tool like jd-gui, decompile the faulty class, fix, recompile that class and replace the .class in the jar.
If it still does not work use ASM and add a close statement at the right place. THIS SOLUTION SHOULD BE AVOIDED. It's complex if you do not master this technology.
I have the following code in a static method:
clips.open(AudioSystem.getAudioInputStream(Sound.class.getResourceAsStream("folder/sound.wav")));
Also, folder is in the same directory as Sound.java. When I run the program in Eclipse, the sound is played. However, when I export the file to a JAR file, the sound no longer plays.
If I change getResourceAsStream() to getResource(), both Eclipse and the JAR file play the sound. Why does this happen? I have read around and many people suggest that getResourceAsStream() simply doesn't work in JAR files. Is this the case, and if so, why not?
I suspect that the issue is that Class.getResourceAsStream(String) returns an InputStream, and Class.getResource(String) returns a URL. Thus, in the first case, we are in effect using
AudioSystem.getAudioInputStream(InputStream inputStream)
and in the second case, using
AudioSystem.getAudioInputStream(URL url).
Why does this matter? I think the main issue is that when the InputStream is the parameter, mark/reset tests are done on your audio file and it is failing. When the URL is used as a parameter, this test does not occur. You might check out the API for AudioSystem.getAudioInputStream to confirm what I am reporting here.
Do you get an error message when the getResourceAsStream fails? Does it mention the mark/reset test error by chance? If you are getting a different error message then this might not be the correct answer and something else is going on.
I have an app which converts jTable instances into an excel file. In my previous question, I had a problem in using FileOutputStream() and it turns out that the problem lies within the AD user's privilege in accessing folders/files. Since my superior wont allow me to change the privileges, I resorted using the FileWriter() instead, which worked well. The only problem is that it kept on warning the users that the file they are opening is corrupt. Here's the warning:
The file you are trying to open, 'filename.xls' is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?
I searched for a solution which resides in Excel 2007's file extension security. Info can be found here
I made some configuration in the system registry of every workstation that the app covers.
I just want to ask if there's a away to remove the corrupt file warning in Office 14, because one of the workstation, which is my superior's workstation, has Office 14. The changes in the system registry didnt stop the corrupt file warning in his workstation.
I get the impression that you are indulging in "voodoo programming" practices; i.e. applying solutions that you don't understand to problems that you don't understand.
Firstly, this:
I had a problem in using FileOutputStream() and it turns out that the problem lies within the AD user's privilege in accessing folders/files. Since my superior wont allow me to change the privileges, I resorted using the FileWriter() instead, which worked well.
Frankly, this doesn't make sense. If you cannot open a file using new FileOutputStream(File), then you shouldn't be able to open it with new FileWriter(File). Why? Because the source code for the constructor is this:
public FileWriter(File file) throws IOException {
super(new FileOutputStream(file));
}
In other words, the first thing that the FileWriter constructor does is to call the FileOutputStream constructor that you say doesn't work!! (And the same applies to the other overloads of these constructors.)
Then your current problem is really about Excel not letting you open an XLS file because its filetype doesn't match its suffix. And your proposed solution is to mess around with the registry. But surely, the CORRECT approach is to find out why the file type doesn't match the suffix.
Have you made a mistaKe in the file format (e.g. 'cos you wrote it using a FileWriter)?
Have you chosen the wrong file suffix for the spreadsheet format you've used?
Are you downloading it to the user's machine with the wrong MIMEtype?
Banging on the registry on all of the client machines ... just because you read it in some website ... that's Voodooo!
I'm not surprised that your boss forbade you to mess around with AD privileges. At this point, he's probably worried that you'll do serious damage.
By the way, your registry hacking to make the warning go away is actually turning off a security check that is designed to help harden the user's PC against attack. That doesn't strike me as a sound solution to your problem.
I had a simple test to make sure that an ant task was behaving properly, and so put in illegal file characters for windows and linux like so:
#Test(expected=BuildException.class)
public void destinationDirectoryCreationException() throws Exception {
backupTask.setSrcDir(testResourceDirectory);
backupTask.setDestDir(new File("?/"));
backupTask.execute();
}
Unfortunately, the reason that / is an illegal file character is that it's the path separator, so this will simply create the directory as normal.
Also char 0 or nul is interpreted by various apis (notably the native file apis and eclipse's debug variable explorer) as the end of stream and so just ignores everything afterwards.
No. Linux is far too awesome to fail for your pathetic little test.
Ok, so osgx actually proposed a solution that will work for my test in particular (if (s)he made an answer, he could get 15 rep ;)); make the directory a sub-directory of one that doesn't exist. e.g. backupTask.setDestDir(new File("/\\/?/"));. The only problem is that it's mildly different from the original test, but I'm ok with that.
Also note that (I believe) it will still succeed in creating the folder if .mkdirs() was called instead of mkdir()
I have a strange problem. When I try to delete a file created by my application it gets deleted and gets replaced with a junk file of the exact same filesize. Can someone please help me out with this? Beats me. The same thing happens when I try to delete the file manually.
are you perhaps using an NFS file system on linux? NFS will leave tombstones behind deleted files in some cases.
(Unless you specify your operating system and post some of your code, this is pure guesswork.)
Since deleting the same file manually causes the same behaviour, it's reasonable to assume that this is not an issue with your code specifically.
Some filesystems (FUSE on Linux comes to mind, as well as some network filesystems) present this behaviour when deleting files that are in use by another process.