I have a vague memory in Windows that when you force deletion of an open  
file, it will invalidate the file descriptors. Thus even if you have a  
stream created, reads after the point of deletion will throw an  
IOException.

If you really need to be able to reproduce a read, you might consider  
using File.createTempFile, copy the source to the temp, and then just  
re-read from temp file, since the probability of other apps mucking with  
temp files might be somewhat lower.

Think of InputStreamReader as a bridge from byte[] to char[].  
BufferedReader provides the decoded char buffer (char[]), but the  
InputStreamReader is still responsible for the binary reading, and thus it  
does maintain it's own private byte[] buffer.

When it comes to streams, once you wrap one stream with another stream,  
any further direct changes to the underling stream (without going through  
the outer stream first) usually result in "undefined" behavior of the  
outer stream. Thus, it's usually best to avoid making such changes.

For your case, if you are using NIO, you can use CharsetDecoder. You  
should be able to create your own ByteBuffer and CharBuffer, and use  
FileChannel.position + CharsetDecoder.reset to reset yourself back to a  
state. Alternatively, you might use  
java.nio.channels.Channels.newReader( <your FileChannel>, <your  
CharsetDecoder> ): just use the postion + reset on the channel + decoder  
and throw away the Reader without closing it - eventually closing the  
channel when you are done.

HTH,

-Zig

Then just use the same file name.  If you really think the file might be
deleted or modified while you are reading it, you will have to take some
action to preserve the integrity of what you're reading.  I have plenty of
programs where I assume that files will not change or be deleted between
accesses even though it is physically possible for an external program or
idiotic user to do so.  Those cases are far too rare to worry about
safeguarding.

Yes, I said implicit locking is needed for that example to work.

If you think this scenario could actually occur and you have a system that
does not honor any locking, I don't know how you will solve the simpler
problem in which you open a file for reading while some other user or
program opens it for writing and proceeds to make changes.  That case is not
preventable. You can't even read the file into memory or copy the file to a
secure area because some other person may try to modify it while you are
copying it.  The upcoming example demonstrates this.

This is not true if the OS does not honor locking because the file contents
can be changed while you're reading it.

On Windows XP, I used the following program to continuously read a file
slowly while I used notepad to modify the file and eventually delete it.
When I saved new file contents (about 18K of repeating but identifiable
text), the program would output the old contents up to about 8K at which
point it would shift to the new contents.  The OS appears to buffer one 8K
block and the file status is checked only when the buffer is refilled.  The
program could not tell that the file contents had changed--it saw only a
continuous stream of characters.  When I truncated the file, it would simply
pick up EOF immediately and when I deleted the file, the program threw an
exception.

   public static void main(String[] args) throws IOException{
       FileInputStream is = new FileInputStream("test.txt");
       FileChannel fc = is.getChannel();

       for(int j=0;j<20;++j){
           InputStreamReader reader = new InputStreamReader(is);
           while (true) {
               int x = reader.read ();
               if (x == -1) break;
               System.out.print((char) x);
               try {
                   Thread.sleep (10);
               } catch (InterruptedException ex) {
                   System.err.println ("Oops");
               }
           }
           reader.close ();

           fc.position(0);
           System.out.println ("****");
       }
   }

After you set fc.position(0), reopen a new InputStreamReader--don't reuse
the old one.  That is, put the new InputStreamReader inside your first for
loop.

The answer to your original question is, yes you can read the same file
twice, but without OS file locking there is no way to ensure that even a
single read will be uncontaminated by external writers. If you can assert
that a single read is correct, read the file into memory or copy it to a
secure location.

Matt Humphrey http://www.iviz.com/

The same file, or the same content?

Between these reads, someone else might append data to the file,
or truncate it, or both, or whatever.

Do you want to be sure, you get the same *data* twice, then you're
probably best off to keep the content in memory during first read
and read from memory next time.
If you're interested in changes on the file, then why worry about
whether the file itself changed or whether it got replaced with a
different one?  Just reopen it by name, and see what's there, this
time.