[
https://issues.apache.org/jira/browse/LUCENE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14318431#comment-14318431
]
Michael McCandless commented on LUCENE-6241:
--------------------------------------------
bq. The user will get IOException if we don't do something, and the IOException
will make it look like a lucene bug to them.
Well, I think that's OK? The IOExc will specific abusing directory they had
added to Lucene's index directory? Plus I think we are talking about very few
actual occurrences of this: it's abusers who also use RAMDir's copy ctor.
Maybe we should simply remove RAMDir's copy ctor? That method seems
abusive/trappy to me too!
> don't filter subdirectories in listAll()
> ----------------------------------------
>
> Key: LUCENE-6241
> URL: https://issues.apache.org/jira/browse/LUCENE-6241
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-6241.patch, LUCENE-6241.patch
>
>
> The issue is, today this means listAll() is always slow, sometimes MUCH
> slower, because it must do the fstat()-equivalent of each file to check if
> its a directory to filter it out.
> When i benchmarked this on a fast filesystem, doing all these filesystem
> metadata calls only makes listAll() 2.6x slower, but on a non-ssd, slower
> i/o, it can be more than 60x slower.
> Lucene doesn't make subdirectories, so hiding these for abuse cases just
> makes real use cases slower.
> To add insult to injury, most code (e.g. all of lucene except for where
> RAMDir copies from an FSDir) does not actually care if extraneous files are
> directories or not.
> Finally it sucks the name is listAll() when it is doing anything but that.
> I really hate to add a method here to deal with this abusive stuff, but I'd
> rather add isDirectory(String) for the rare code that wants to filter out,
> than just let stuff always be slow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
