lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Serebrennikov <dmit...@earthlink.net>
Subject FSInputStream strangeness
Date Sat, 20 Sep 2003 21:04:53 GMT
Greetings,

I'm developing some test cases to verify that my filehandle fix works, 
and in the process I am comparing the behavior of my InputStream classes 
with the FSInputStreams. I'm finding that FSInputStream behaves in 
strange ways sometimes, and I'm wandering if I should emulate its 
behavior to avoid breaking things or rather treat these issues as bugs 
in FSInputStream to be fixed later, and code my stuff to behave as I 
think it should.

There are two such issues I found so far. Has anyone seen this before? 
Is this intentional? Does some functionality depend on these?

- seek() calls with negative arguments or with arguments greater than 
the file length appear to succeed
- reading from a stream after a call to close() also succeeds (at least 
some times).

I think both of these are related to buffering that is performed by 
FSInputStream. Calls to close() do not clear this buffer and subsequent 
read calls that do not require a refill of the buffer are allowed to 
succeed.

Any comments?

Dmitry.



Mime
View raw message