One thing I saw while tracing back the clone() call is that InputStream.clone() has this remark:
Expert: Subclasses must ensure that clones may be positioned at different points in the input from each other and from the stream they were cloned from.
I'm not actually certain if that's the case for FSInputStream. As I see it I don't think the file variable in the FSInputStream class will be cloned correctly and will cause issues when cloned InputStreams are used.
FSInputStream.file is shared between all clones of an open file. Access to it is synchronized. This works correctly. Cloned input streams are already used extensively.
The solution I think is to recreate the FSInputStream.file object whenever a FSInputStream is cloned. I've attached what I think is a fix for the issue below.
This would cause lots more file handles to be opened, and would also fail once a file has been deleted. On UNIX, an open file handle may be used after it is deleted, and Lucene leverages this so that updates can occur while an index is still being searched. I don't think there's a bug here to be fixed.
Doug
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
