I have a little doubt about following code:
try {
File file = new File("writing");
file.createNewFile();
System.out.println(file.delete());
System.out.println(file.exists());
PrintWriter pw = new PrintWriter(file);
pw.print(324.2342);
pw.flush();
pw.close();
FileReader fr = new FileReader(file);
BufferedReader br = new BufferedReader(fr);
System.out.println(br.readLine());
br.close();
} catch(IOException ioE) {
System.out.println("Indeed");
}
Why in this circumstance the method file.delete() apparently says that it works as it returns "true" when executed and it gets also confirmed by the file.exists() method which returns "false". However at runtime I do not get any exception like "IOException the file "writing" does not exist" or something likewise.
Why does the file keep staying in the heap even though deleted physically? Shouldn't it be automatically garbage collected as soon as the delete method gets called? I know it does not because I saw the output.
This is because the File represents a abstract path, see the JavaDoc for it http://docs.oracle.com/javase/6/docs/api/java/io/File.html. It does not represent a file handle in the OS.
The line in your code:
PrintWriter pw = new PrintWriter(file);
Simply creates a new file. Try deleting the file after calling this...
File object represents a path to a physical file on the file system either exists or not. That's why you have exists() (to check if it exists) and createNewFile() (to create the file if it is not found).
Also note that PrintWriter(File file) creates a new file if it does not exist.
Parameters:
file - The file to use as the destination of this writer. If the file
exists then it will be truncated to zero size; otherwise, a new file
will be created. The output will be written to the file and is
buffered.
The File is handle to real file (that exists or not). You create and then delete the file above, as you say - all good so far.
When you come to the PrintWriter later on it creates the file once more when you use it - it doesnt matter that you deleted it before.
In fact depending on your use case this might be exaclty wht you want - you may want to delete an old log file for example before re-createing and writing to it once more.
Finally, nothing in your code will be eligible for garbage collection until your method exist, and even then the underyling file will continue to exist (if you dont delete it agin) - and any garbage colleciton in this case wouldnt effect the underlying file. It'll be deleted after the delete invokation and exist again once youre PrintWriter is done with it.
Hope this helps!
The file doesn't have a link to a particular file, rather to any file pointer by the file's path. With this line you're creating a new file:
PrintWriter pw = new PrintWriter(file);
Related
Recently I am doing a code review, the code is like this:
File j = new File(aFile);
System.out.println(j.length());
BufferedReader fileReader = new BufferedReader(new FileReader(j));
BufferedWriter fileWriter = new BufferedWriter(new FileWriter(aFile.getPath());
System.out.println(j.length());
I have two questions:
Is j a duplicate of aFile, because I have seen other huge methods for copying files, like here.
The first System.out.println() prints 32 and the second, after creating a file reader, prints 0. So, why are the contents getting deleted? Could someone explain what's happening here?
I put those System.out.println() statements to check if the file is empty or not.
Solution:
After Reading through the answers, I think I found what's wrong with the code. If j is just a reference, then the fileWriter is trying to write into the same file and it is cyclic. Am I right here?
EDIT: This is not a duplicate of suggested question, as the whole confusion was thinking that the j is clone or duplicate of aFile.
You're not showing us everything, are you?
The presented code definitely does not change or delete the file, as is already indicated by the names of the classes you are using: BufferedReader, FileReader (note Reader in both).
I thought there might be a slim chance that some operating systems would lock the file once you create the Readers, hence not even allowing a File object to read the length() property anymore. However, I couldn't find that documented or reported anywhere, so I highly doubt it.
I ran the following code, where test is a plain text file containing 0123456789 (length 10):
import java.io.BufferedReader;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
public class StackOverflow {
public static void main(String[] args) {
File f = new File("test");
System.out.println("Length before: " + f.length());
try {
BufferedReader fileReader = new BufferedReader(new FileReader(f));
} catch (FileNotFoundException e) {
e.printStackTrace();
}
System.out.println("Length after: " + f.length());
}
}
Result:
Length before: 10
Length after: 10
Hence, I suspect the issue lies elsewhere.
EDIT:
Now that OP updated the question, we finally have the relevant line:
BufferedWriter fileWriter = new BufferedWriter(new FileWriter(aFile.getPath());
That's why the file is empty and its length 0. FileWriter will open the file for writing and overwrite the existing contents, if any. You can prevent this by passing in a second parameter, making use of another constructor of FileWriter, one that accepts an append flag:
public FileWriter(String fileName, boolean append) throws IOException
public FileWriter(File file, boolean append) throws IOException
Constructs a FileWriter object given a File object/name. If the second argument is true, then bytes will be written to the end of the file rather than the beginning.
In other words, if you don't want the contents to be overridden, change your above line to:
BufferedWriter fileWriter = new BufferedWriter(new FileWriter(aFile.getPath(), true);
1) j is not a duplicate, it is a reference to a new file object that wraps the actual file.
2) There is no way this code should delete (or even change) the file. Is there any more code?
1) Is j a duplicate of aFile, because I have seen other huge methods for copying files, like here and here.
It is a File object constructed from aFile, whatever that may be. This process has nothing whatsoever to do with copying files, whether huge or hugely or otherwise. File just wraps a file name. Not its contents. Your first link has nothing to do with copying files either.
2) The first result prints 32 and the second result after creating a file reader prints 0. So, why are the contents getting deleted?
Obviously this is not the real code. The real test is whether fileReader.read() immediately returns -1.
I'm working with the FileOutputStream class in java, but I don't know how to delete "the contents" of a file (the main reason i need overwrite the file).
If you want to delete the contents of the file, but not the file itself, you could do:
PrintWriter pw = new PrintWriter("file.txt");
pw.close();
A few seconds of Googling got me this:
how to delete the content of text file without deleting itself
How to clear a text file without deleting it?
To delete the file completely, do:
File file = new File("file.txt");
f.delete();
Call File.delete() which deletes the file or directory denoted by this abstract pathname.
File f = new File("foo.txt");
if (f.delete()) {
System.out.println("file deleted");
}
The main reason i need overwrite the file ...
One way to do this is to delete the file using File.delete() or Files.delete(Path). The latter is preferable, since it can tell you why the deletion fails.
The other way is to simply open the file for writing. Provided that you don't open in "append" mode, opening a file to write will truncate the file to zero bytes.
Note that there is a subtle difference in the behavior of these two approaches. If you delete a file and then create a new one, any other application that has the same file open won't notice. By contrast, if you truncate the file, then other applications with the file open will observe the effects of the truncation when they read.
Actually, this is platform dependent. On some platforms, a Java application that tries to open a file for reading that another file has open for writing will get an exception.
Yes, you can do it with FileOutputStream. All the answers given say about PrintWriter but the same can be done with FileOutputStream. The int representation of space is 32. So simply pass the file to the instance of FileOutputStream as:
FileOutputStream out = new FileOutputStream(file);
out.write(32);
This will clear the contents of the file. Surely use this only of u want to do it with FileOutputStream only otherwise use PrintWriter.
I actually checked other posts that could be related to this and I couldn't find any answer to my question. So, had to create this newly:
The file does not get created in the given location with this code:
File as = new File ("C:\\Documents and Settings\\<user>\\Desktop\\demo1\\One.xls");
if (!as.exists()) {
as.createNewFile();
}
FileOutputStream fod = new FileOutputStream(as);
BufferedOutputStream dob = new BufferedOutputStream(fod);
byte[] asd = {65, 22, 123};
byte a1 = 87;
dob.write(asd);
dob.write(a1);
dob.flush();
if (dob!=null){
dob.close();
}
if(fod!=null){
fod.close();
The code runs fine and I don't get any FileNotFoundException!!
Is there anything that I'm missing out here?
You can rewrite your code like this:
BufferedOutputStream dob = null;
try {
File file = new File("C:\\Documents and Settings\\<user>\\Desktop\\demo1\\One.xls");
System.out.println("file created:" + file.exists());
FileOutputStream fod = new FileOutputStream(file);
System.out.println("file created:" + file.exists());
BufferedOutputStream dob = new BufferedOutputStream(fod);
byte[] asd = {65, 22, 123};
byte a1 = 87;
dob.write(asd);
dob.write(a1);
//dob.flush();
}
catch (Exception ex) {
ex.printStackTrace();
}
finally {
if (dob != null) {
dob.close();
}
}
In this case it is only necessary to call the topmost stream handler close() method - the BufferedOutputStream's one:
Closes this output stream and releases any system resources associated with the stream.
The close method of FilterOutputStream calls its flush method, and then calls the close method of its underlying output stream.
so, the dob.flush() in try block is commented out because the dob.close() line in the finally block flushes the stream. Also, it releases the system resources (e.g. "closes the file") as stated in the apidoc quote above. Using the finally block is a good practice:
The finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. But finally is useful for more than just exception handling — it allows the programmer to avoid having cleanup code accidentally bypassed by a return, continue, or break. Putting cleanup code in a finally block is always a good practice, even when no exceptions are anticipated.
The FileOutputStream constructor creates an empty file on the disk:
Creates a file output stream to write to the file represented by the specified File object. A new FileDescriptor object is created to represent this file connection.
First, if there is a security manager, its checkWrite method is called with the path represented by the file argument as its argument.
If the file exists but is a directory rather than a regular file, does not exist but cannot be created, or cannot be opened for any other reason then a FileNotFoundException is thrown.
Where a FileDescriptor is:
Instances of the file descriptor class serve as an opaque handle to the underlying machine-specific structure representing an open file, an open socket, or another source or sink of bytes. The main practical use for a file descriptor is to create a FileInputStream or FileOutputStream to contain it.
Applications should not create their own file descriptors.
This code should either produce a file or throw an exception. You have even confirmed that no conditions for throwing exception are met, e.g. you are replacing the string and the demo1 directory exists. Please, rewrite this to a new empty file and run.
If it still behaving the same, unless I have missed something this might be a bug. In that case, add this line to the code and post output:
System.out.println(System.getProperty("java.vendor")+" "+System.getProperty("java.version"));
Judging from the path, I'd say you are using Win 7, am I right? What version?
Then it means there is a file already in your directory
I am using this piece of code to create a temporary file:
String tmpDirectoryOp = System.getProperty("java.io.tmpdir");
File tmpDirectory = new File(tmpDirectoryOp);
File fstream = File.createTempFile("tmpDirectory",".flv", tmpDirectory);
FileOutputStream fos = new FileOutputStream(fstream);
DataOutputStream dos=new DataOutputStream(fos);
dos.writeChars("Write something");
fstream.deleteOnExit();
fos.close();
dos.close();
But there is no tmpDirectory.flv in my project folder. The write sentence is in a loop, which takes quite long time to finish, so the problem is not that the file is deleted before I could see it.
Any idea? Thanks in advance
Creates an empty file in the default
temporary-file directory, using the
given prefix and suffix to generate
its name. Invoking this method is
equivalent to invoking
createTempFile(prefix, suffix, null).
You can get temp dir for your operating system using
System.getProperty("java.io.tmpdir");
You have executed deleteOnExit()
public void deleteOnExit()
Requests that the file or directory
denoted by this abstract pathname be
deleted when the virtual machine
terminates. Deletion will be attempted
only for normal termination of the
virtual machine, as defined by the
Java Language Specification. Once
deletion has been requested, it is not
possible to cancel the request. This
method should therefore be used with
care.
Note: this method should not be used
for file-locking, as the resulting
protocol cannot be made to work
reliably. The FileLock facility should
be used instead.
Documentation
!! Please close the streams !!
File fstream = File.createTempFile("tmpDirectory",".flv");
FileOutputStream fos = new FileOutputStream(fstream);
DataOutputStream dos=new DataOutputStream(fos);
dos.writeChars("Write something");
fstream.deleteOnExit();
**
fos.close();
dos.close();
**
Have you looked in your /tmp folder?
If you want to create a temporary file in a specified folder, you need the 3 param createTempFile function
Try to flush and close the stream.
I have a Java code that reads through an input file using a buffer reader until the readLine() method returns null. I need to use the contents of the file again indefinite number of times. How can I read this file from beginning again?
You can close and reopen it again. Another option: if it is not too large, put its content into, say, a List.
Buffer reader supports reset() to a position of buffered data only. But this cant goto the begin of file (suppose that file larger than buffer).
Solutions:
1.Reopen
2.Use RandomAccessFile
A single Reader should be used once to read the file. If you want to read the file again, create a new Reader based on it.
Using Guava's IO utilities, you can create a nice abstraction that lets you read the file as many times as you want using Files.newReaderSupplier(File, Charset). This gives you an InputSupplier<InputStreamReader> that you can retrieve a new Reader from by calling getInput() at any time.
Even better, Guava has many utility methods that make use of InputSuppliers directly... this saves you from having to worry about closing the supplied Reader yourself. The CharStreams class contains most of the text-related IO utilities. A simple example:
public void doSomeStuff(InputSupplier<? extends Reader> readerSupplier) throws IOException {
boolean needToDoMoreStuff = true;
while (needToDoMoreStuff) {
// this handles creating, reading, and closing the Reader!
List<String> lines = CharStreams.readLines(readerSupplier);
// do some stuff with the lines you read
}
}
Given a File, you could call this method like:
File file = ...;
doSomeStuff(Files.newReaderSupplier(file, Charsets.UTF_8)); // or whatever charset
If you want to do some processing for each line without reading every line into memory first, you could alternatively use the readLines overload that takes a LineProcessor.
you do this by calling the run() function recursively, after checking to see if no more lines can be read - here's a sample
// Reload the file when you reach the end (i.e. when you can't read anymore strings)
if ((sCurrentLine = br.readLine()) == null) {
run();
}
If you want to do this, you may want to consider a random access file. With that you can explicitly set the position back to the beginning and start reading again from there.
i would suggestion usings commons libraries
http://commons.apache.org/io/api-release/org/apache/commons/io/FileUtils.html
i think there is a call to just read the file into a byteArray which might be an alternate approach
Not sure if you have considered the mark() and reset() methods on the BufferedReader
that can be an option if your files are only a few MBs in size and you can set the mark at the beginning of the file and keep reset()ing once you hit the end of the file. It also appears that subsequent reads on the same file will be served entirely from the buffer without having to go to the disk.
I faced with the same issue and came wandering to this question.
1. Using mark() and reset() methods:
BufferedReader can be created using a FileReader and also a FileInputStream. FileReader doesn't support Mark and Reset methods. I got an exception while I tried to do this. Even when I tried with FileInputStream I wasn't able to do it because my file was large (even your's is I guess). If the file length is larger than the buffer then mark and reset methods won't work neither with FileReader not with FileInputStream. More on this in this answer by #jtahlborn.
2. Closing and reopening the file
When I closed and reopened the file and created a new BufferedReader, it worked well.
The ideal way I guess is to reopen the file again and construct a new BufferedReader as a FileReader or FileInputStream should be used only once to read the file.
try {
BufferedReader br = new BufferedReader(new FileReader(input));
while ((line = br.readLine()) != null)
{
//do somethng
}
br.close();
}
catch(IOException e)
{
System.err.println("Error: " + e.getMessage());
}
}