Tomas Mikula said:
I am not seriously concerned about it.
I just want to make sure I read the same file.
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.
Without locking this will not work (at least not on Unix-like systems) and
if
write lock does not restrain from file removal (which is write access to
directory, not the file), then even lock will not help.
Yes, I said implicit locking is needed for that example to work.
Imagine this scenario:
- my program opens the file
- somebody else renames or removes the file (the file will disappear from
directory, but it's open file descriptors still work)
- optionally: another file with the same name is created
- I try to open the file with filename again, but either it does not exist
or
is another file
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.
So if I open the file just once, I can be sure I'm still working with the
same
file.
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 ("****");
}
}
It may also be possible (I haven't tried this but it's a fairly easy
test)
to open your file as a FileInputStream, get the stream's FileChannel and
then reset the position of that channel.
I just tried it and it works when I am reading from that FileInputStream,
but not when I create InputStreamReader from that FileInputStream.
Here is my code:
public static void main(String[] args) throws IOException{
FileInputStream is = new FileInputStream("input");
FileChannel fc = is.getChannel();
InputStreamReader reader = new InputStreamReader(is);
for(int j=0;j<2;++j){
for(int i=0; i<5; ++i){
int x = is.read(); /* (X) */
if(x==-1)
System.exit(1);
System.out.print((char) x);
}
fc.position(0);
}
}
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.
File "input" contains text "0123456789".
When I run this program, it outputs
"0123401234" as expected.
But when I change the line marked with /* (X) */ to
int x = reader.read();
then I get this output:
"0123456789", so the fc.position(0) had no effect.
Maybe there is some buffering in InputStreamReader,
but that I would expect only from BufferedReader.
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/