I'm trying to get this piece of code to work. It's a basic I/O system that copies one file and pastes it into the same directory with the chosen name. It should be simple but for some reason the program runs, it creates the second file but then it gets stuck. The CPU for Java process sits at around 5% and the file is never completed. It only copies over some of the data and then I'd imagine it's stuck in an infinite loop somewhere.
I've already compared my code with the Byte Streams tutorial on the Oracle website.
EXTRA: I just asked it to output what it was reading and it's stuck on an infinite loop reading the value 255. If that helps. Also, I compiled the code directly off the Oracle website and it does the same thing.
It appears consistent from what I can tell. Can anyone tell me what I'm doing wrong? Thank you.
(P.S: I'm Using Eclipse 4.2.0).
This is what I'm doing to copy the file:
package fileIO;
import java.io.*;
import system.Debug;
public class fileUtil {
public static void copyFileTo(String file2Copy, String file2Paste) {
FileInputStream fin = null;
FileOutputStream fout = null;
try {
fin = new FileInputStream(file2Copy);
fout = new FileOutputStream(file2Paste);
int aByte;
while ((aByte = fin.read()) != -1) {
fout.write(aByte);
}
} catch (FileNotFoundException e) {
Debug.out("Error: File Not Found: " + file2Copy);
} catch (IOException e) {
Debug.out("Error: File IO Exception Copying: " + file2Copy);
} catch (Exception e) {
Debug.out("Error: General Exception Closing Streams:" + file2Copy);
} finally {
try {
fin.close();
fout.close();
} catch (IOException e) {
Debug.out("Error: File IO Exception Closing Streams: " + file2Copy);
} catch (Exception e) {
Debug.out("Error: General Exception Closing Streams:" + file2Copy);
}
}
}
}
In my program main class I run this:
fileUtil.copyFileTo("google.bmp", "google(1).bmp");
Try to do fout.flush() before you close the OutputStream.
Okay, so I found out what was happening. Was a really nooby mistake.
I'll put my pride aside encase anyone else has this problem. It's not an infinite loop, it's just that copying using ByteStreams takes AGES. I was expecting a fast result from small image files but even small image files take a long long time to copy. I let it run for 30 seconds and the program terminated properly and I got my image copy just fine.
Thank god it's solved, I was beginning to worry.
... or do not invent bother re-inventing the wheel: use FileUtils.copyFile from the proven Apache commons-io which does it in one line.
(beware: this comment is not as innocent as it seems: File.rename does not work well on Windows shares - commons-io is always the safe bet to do these things)
Edit
Stackoverflow is not a goog place for "homework" - or you must at least say so. It is not that your problem is not real. It is that your objectives differ: you want to learn something, we want to make it work reliably with minimum maintenance.
...which leads to my second point: when you are in professional life, never program this again. As you discovered, even if you make it work, it may be extremely inefficient, handle errors incorrectly, etc.. This is particularly true with IO which is always more tricky than it seems.
Finally, since I gave you a link to a well trusted library under Apache 2.0 license, maybe you could have had a look at the source code ?
Related
when I am reading the code of opentsdb:
try {
System.in.close(); // Release a FD we don't need.
} catch (Exception e) {
log.warn("Failed to close stdin", e);
}
After searching this question on the Internet, I can't find a suitable answer. I don't understand why they write system.in.close(), and I want to know if we don't add this code block, what will happen?
Probably only if you used System.setIn() to override the standard input. One normally does not close the standard input, it's handled by JVM process shutdown.
I have researched this issue for quite some time on google and stackoverflow.
Unfortunately, I can't seem to find any resources that seem to address this issue. Admittedly, my search-fu isn't the best; any help, examples, or pointers to relevant resources will be very much appreciated.
The following code is my method for listing the archive contents from a TarArchiveInputStream:
public static List<String> tarListDir(InputStream incoming)
throws Exception {
TarArchiveInputStream tarInput = new TarArchiveInputStream(incoming);
TarArchiveEntry entry = null;
List<String> ouah = new ArrayList<String>();
try {
while ((entry = tarInput.getNextTarEntry()) != null) {
if (!entry.isFile()) {
continue;
}
ouah.add(entry.getName());
if (RecScan.verbose || RecScan.debugging) {
if (entry.isFile()) {
System.out.print("file: \t");
} else if (entry.isDirectory()) {
System.out.print("dir: \t");
} else {
System.out.print("wut: \t");
}
System.out.println(ouah.get(ouah.size() - 1));
}
}
} catch (Exception e) {
tarInput.close();
throw new Exception("Closed w/exception: " + e.getMessage());
}
if (RecScan.verbose || RecScan.debugging) {
System.out.println("Closing tarInput normally");
}
tarInput.close();
return ouah;
}
As mentioned above, I am hoping to obtain the List of entries in the archive. Unfortunately, it appears that the method is only obtaining a random amount of directory entries. This number varies, per-archive (testing with 4 different ones), from 0 entries to 12 entries. The exception that is being thrown is an IOException, Stream Closed to be specific.
I'm not very well versed in the Apache Commons Compress libraries (obviously), and I don't really know any hex editors well enough to dig around in the archive to see if there's something non-POSIX that it's stumbling over. I would think that the entry.isFile() conditional would avoid that complication, though.
As I mentioned, any help or resources greatly appreciated! TIA!
EDIT: Though the code there (in the first comment's post reference) seemed to boil down basically to the same as what I was using, I did actually cut out my code and use what was there, virtually verbatim. Still got the exact same error: Stream Closed. I did manage to find something that may hold a clue; I tried swapping out the BufferedInputStream wrapping of the original InputStream that I handed off. This caused the Stream Closed error immediately, vs. the BufferedInputStream closing after a bit of the archive listing. Definitely still looking for hints.
I am currently using Eclipse Java Neon for my builder, and I am trying to implement a save and load feature into a project i am currently working on. I know it requires me to use a Try/Catch block, but I have no idea how to really handle it. Not only that, but what I tried out is giving me a bit of an error:
try {
System.out.println("Writing to file...");
charWrite = new FileWriter("player.dat");
charWrite.write(player.getName()); //String
charWrite.write(player.getJob()); //String
charWrite.write(player.getLevel()); //Int
charWrite.write(player.getCurrency()); //Int
charWrite.write(player.getHealth()); //Int
charWrite.write(player.getExp()); //Int
}
catch (IOException excpt) {
System.out.println("Caught IOException: " + excpt.getMessage());
}
The system seems to recognize what is happening, but when I go to open it and see if it has written, the document is still blank.
And if I am this lost on writing, I am going to be so lost when reading to place it into the Class's parameters.
Thanks for the help.
You are trying to write an object of type java.lang.Class to a file. If you want the String representation of the class name use toString():
charWrite.write(player.getClass().toString());
This question already has answers here:
JAVA NIO Watcher: How to detect end of a long lasting (copy) operation?
(2 answers)
Closed 8 years ago.
I am writing a directory monitoring utility in java(1.6) using polling at certain intervals using lastModified long value as the indication of change. I found that when my polling interval is small (seconds) and the copied file is big then the change event is fired before the actual completion of file copying.
I would like to know whether there is a way I can find the status of file like in transit, complete etc.
Environments: Java 1.6; expected to work on windows and linux.
There are two approaches I've used in the past which are platform agnostic.
1/ This was for FTP transfers where I controlled what was put, so it may not be directly relevant.
Basically, whatever is putting a file file.txt will, when it's finished, also put a small (probably zero-byte) dummy file called file.txt.marker (for example).
That way, the monitoring tool just looks for the marker file to appear and, when it does, it knows the real file is complete. It can then process the real file and delete the marker.
2/ An unchanged duration.
Have your monitor program wait until the file is unchanged for N seconds (where N is reasonably guaranteed to be large enough that the file will be finished).
For example, if the file size hasn't changed in 60 seconds, there's a good chance it's finished.
There's a balancing act between not thinking the file is finished just because there's no activity on it, and the wait once it is finished before you can start processing it. This is less of a problem for local copying than FTP.
This solution worked for me:
File ff = new File(fileStr);
if(ff.exists()) {
for(int timeout = 100; timeout>0; timeout--) {
RandomAccessFile ran = null;
try {
ran = new RandomAccessFile(ff, "rw");
break; // no errors, done waiting
} catch (Exception ex) {
System.out.println("timeout: " + timeout + ": " + ex.getMessage());
} finally {
if(ran != null) try {
ran.close();
} catch (IOException ex) {
//do nothing
}
ran = null;
}
try {
Thread.sleep(100); // wait a bit then try again
} catch (InterruptedException ex) {
//do nothing
}
}
System.out.println("File lockable: " + fileStr +
(ff.exists()?" exists":" deleted during process"));
} else {
System.out.println("File does not exist: " + fileStr);
}
This solution relies on the fact that you can't open the file for writing if another process has it open. It will stay in the loop until the timeout value is reached or the file can be opened. The timeout values will need to be adjusted depending on the application's actual needs. I also tried this method with channels and tryLock(), but it didn't seem to be necessary.
Do you mean that you're waiting for the lastModified time to settle? At best that will be a bit hit-and-miss.
How about trying to open the file with write access (appending rather than truncating the file, of course)? That won't succeed if another process is still trying to write to it. It's a bit ugly, particularly as it's likely to be a case of using exceptions for flow control (ick) but I think it'll work.
If I understood the question correctly, you're looking for a way to distinguish whether the copying of a file is complete or still in progress?
How about comparing the size of the source and destination file (i.e. file.length())? If they're equal, then copying is complete. Otherwise, it's still in progress.
I'm not sure it's efficient since it would still require polling. But it "might" work.
You could look into online file upload with progressbar techniques - they use OutputStreamListener and custom writer to notify the listener about bytes written.
http://www.missiondata.com/blog/java/28/file-upload-progress-with-ajax-and-java-and-prototype/
File Upload with Java (with progress bar)
We used to monitor the File Size change for determine whether the File is inComplete or not.
we used Spring integration File endpoint to do the polling for a directory for every 200 ms.
Once the file is detected(regardless of whether it is complete or not), We have a customer File filter, which will have a interface method "accept(File file)" to return a flag indicating whether we can process the file.
If the False is returned by the filter, this FILE instance will be ignored and it will be pick up during the next polling for the same filtering process..
The filter does the following:
First, we get its current file size. and we will wait for 200ms(can be less) and check for the size again. If the size differs, we will retry for 5 times. Only when the file size stops growing, the File will be marked as COMPLETED.(i.e. return true).
Sample code used is as the following:
public class InCompleteFileFilter<F> extends AbstractFileListFilter<F> {
protected Object monitor = new Object();
#Override
protected boolean accept(F file) {
synchronized (monitor){
File currentFile = (File)file;
if(!currentFile.getName().contains("Conv1")){return false;}
long currentSize = currentFile.length();
try { Thread.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); }
int retryCount = 0;
while(retryCount++ < 4 && currentFile.length() > currentSize){
try { Thread.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); }
}
if(retryCount == 5){
return false;
}else{
return true;
}
}
}
}
This question already has answers here:
JAVA NIO Watcher: How to detect end of a long lasting (copy) operation?
(2 answers)
Closed 8 years ago.
I am writing a directory monitoring utility in java(1.6) using polling at certain intervals using lastModified long value as the indication of change. I found that when my polling interval is small (seconds) and the copied file is big then the change event is fired before the actual completion of file copying.
I would like to know whether there is a way I can find the status of file like in transit, complete etc.
Environments: Java 1.6; expected to work on windows and linux.
There are two approaches I've used in the past which are platform agnostic.
1/ This was for FTP transfers where I controlled what was put, so it may not be directly relevant.
Basically, whatever is putting a file file.txt will, when it's finished, also put a small (probably zero-byte) dummy file called file.txt.marker (for example).
That way, the monitoring tool just looks for the marker file to appear and, when it does, it knows the real file is complete. It can then process the real file and delete the marker.
2/ An unchanged duration.
Have your monitor program wait until the file is unchanged for N seconds (where N is reasonably guaranteed to be large enough that the file will be finished).
For example, if the file size hasn't changed in 60 seconds, there's a good chance it's finished.
There's a balancing act between not thinking the file is finished just because there's no activity on it, and the wait once it is finished before you can start processing it. This is less of a problem for local copying than FTP.
This solution worked for me:
File ff = new File(fileStr);
if(ff.exists()) {
for(int timeout = 100; timeout>0; timeout--) {
RandomAccessFile ran = null;
try {
ran = new RandomAccessFile(ff, "rw");
break; // no errors, done waiting
} catch (Exception ex) {
System.out.println("timeout: " + timeout + ": " + ex.getMessage());
} finally {
if(ran != null) try {
ran.close();
} catch (IOException ex) {
//do nothing
}
ran = null;
}
try {
Thread.sleep(100); // wait a bit then try again
} catch (InterruptedException ex) {
//do nothing
}
}
System.out.println("File lockable: " + fileStr +
(ff.exists()?" exists":" deleted during process"));
} else {
System.out.println("File does not exist: " + fileStr);
}
This solution relies on the fact that you can't open the file for writing if another process has it open. It will stay in the loop until the timeout value is reached or the file can be opened. The timeout values will need to be adjusted depending on the application's actual needs. I also tried this method with channels and tryLock(), but it didn't seem to be necessary.
Do you mean that you're waiting for the lastModified time to settle? At best that will be a bit hit-and-miss.
How about trying to open the file with write access (appending rather than truncating the file, of course)? That won't succeed if another process is still trying to write to it. It's a bit ugly, particularly as it's likely to be a case of using exceptions for flow control (ick) but I think it'll work.
If I understood the question correctly, you're looking for a way to distinguish whether the copying of a file is complete or still in progress?
How about comparing the size of the source and destination file (i.e. file.length())? If they're equal, then copying is complete. Otherwise, it's still in progress.
I'm not sure it's efficient since it would still require polling. But it "might" work.
You could look into online file upload with progressbar techniques - they use OutputStreamListener and custom writer to notify the listener about bytes written.
http://www.missiondata.com/blog/java/28/file-upload-progress-with-ajax-and-java-and-prototype/
File Upload with Java (with progress bar)
We used to monitor the File Size change for determine whether the File is inComplete or not.
we used Spring integration File endpoint to do the polling for a directory for every 200 ms.
Once the file is detected(regardless of whether it is complete or not), We have a customer File filter, which will have a interface method "accept(File file)" to return a flag indicating whether we can process the file.
If the False is returned by the filter, this FILE instance will be ignored and it will be pick up during the next polling for the same filtering process..
The filter does the following:
First, we get its current file size. and we will wait for 200ms(can be less) and check for the size again. If the size differs, we will retry for 5 times. Only when the file size stops growing, the File will be marked as COMPLETED.(i.e. return true).
Sample code used is as the following:
public class InCompleteFileFilter<F> extends AbstractFileListFilter<F> {
protected Object monitor = new Object();
#Override
protected boolean accept(F file) {
synchronized (monitor){
File currentFile = (File)file;
if(!currentFile.getName().contains("Conv1")){return false;}
long currentSize = currentFile.length();
try { Thread.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); }
int retryCount = 0;
while(retryCount++ < 4 && currentFile.length() > currentSize){
try { Thread.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); }
}
if(retryCount == 5){
return false;
}else{
return true;
}
}
}
}