Doug Cutting schrieb:
> Dmitry Serebrennikov wrote:
>
>> There are two such issues I found so far. Has anyone seen this before?
>> Is this intentional? Does some functionality depend on these?
>
>
> I don't think they're intentional, and nothing should depend on them.
>
>> - 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.
>
Closing a FSInputStream only closes the underlying file if the FSInputStream
is not a clone. If close is called for a clone it does nothing and the
respective FSInputStream still works. Calls to readByte() are still possible
even outside the buffer. I think this behavior of close() is acceptable
since the only thing close really has to do is free resources if possible.
However, I found a place where the code currently relies on this behavior.
DateFilter closes a TermDocs in bits(reader) and uses it again later. The
code only works since SegmentTermReader keeps a copy of freqStream and thus
SegmentTermDocs cannot close the underlying file, it only has control on a
clone of freqStream.
I attach a patch for DateFilter that moves the termDocs.close() to the right
place. Since this patch does not solve any bug, I do not have any new test.
I tried TestDateFilter with my changes and it still works.
Christoph
--
*****************************************************************
* Dr. Christoph Goller Tel.: +49 89 203 45734 *
* Detego Software GmbH Mobile: +49 179 1128469 *
* Keuslinstr. 13 Fax.: +49 721 151516176 *
* 80798 München, Germany Email: goller@detego-software.de *
*****************************************************************
|