This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
especially the read method
The first line calls binputStream.read(buf), assigns its return value (the actual number of read bytes) to len, and then checks if len > 0. You should change this to >= 0 though, because it's quite possible that nothing is read now, but some data may still arrive later. -1 really means nothing is available and nothing will be available.
Now, buf contains all newly read bytes. However, if len < buf.length, then everything from buf[len] onwards is old data, from a previous read (or perhaps still 0 from the array initializing). By calling bout.write(buf, 0, len), you are specifying that only the array elements from 0 to len (exclusive) should be written - the bytes you've actually just read.
if i do it this way
A file newfile.txt of more than 1 GB is created and it's size keeps increasing
and the program hangs
why does it happen
You are reading data from the file only once, then keep writing that same block over and over and over again. If len > 0, then len will remain > 0.
fill the byte array buf with the contents of the file I give at command prompt
Yes it does. The read method tries to read as many bytes as possible to fill the array, and returns the number of bytes actually read.
this line,strange because it is .read(buf)
this line i believe writes the contents of buf to newfile.txt
but i guess it is not deleted from buf,it is copied
Exactly. buf keeps all of its values until you fill it again. And if it can only be partly filled, the part that cannot be filled will still keep its old values. That's why you only write from 0 to len.
but how does the value of variable len reduce? which is necessary to come out of while loop
read returns the number of bytes actually read. You never know how many that will be, except for the following
- it will always be at most buf.length
- it will always be at least 0 if the file has not been read completely yet
- it will be -1 if the file has been read completely.
By keeping calling read, a little more of the file is read each time. Then after a while all of it is read, and -1 is returned. You then know that you're done.
An example. Consider a file with size 5.5kB (5632 bytes). Your array size is 1024.
- read: the first 1024 bytes are read; 1024 is returned; 4608 bytes remain
- read: the next 1024 bytes are read; 1024 is returned; 3584 bytes remain
- read: only 768 bytes are read; 768 is returned; 2816 bytes remain
- read: the next 1024 bytes are read; 1024 is returned; 1792 bytes remain
- read: the next 1024 bytes are read; 1024 is returned; 768 bytes remain
- read: the last 768 bytes are read; 768 is returned; 0 bytes remain
- read: there is nothing to read; -1 is returned
Should you call read again after that, it will again return -1.
Also note that the third read only could read 768 bytes. Although for local files this does not happen that much, it could happen because the disk is busy with other things perhaps. If you read other InputStreams, like one from a Socket or URL, it is quite normal to have less bytes available than requested.
Joined: Jul 01, 2009
You explained it very well,meticulously I think is the word