Rob, what is the intended behavior, and what is the reasoning behind it? Doesn't this affect only attempts to open a non-existent index directory - and whether or not there will be an empty folder left behind?
-- Itamar Syn-Hershko http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer & Consultant Lucene.NET committer and PMC member On Wed, Feb 4, 2015 at 2:45 PM, Robert Muir <[email protected]> wrote: > Personally, I am completely against changing this for 5.0 > > This is the worst possible thing you can do, it will trickle into more > bugs in lockfactory etc. Please don't make this last minute risky > change. it has no benefits and will only cause bugs. > > On Wed, Feb 4, 2015 at 7:44 AM, Robert Muir <[email protected]> wrote: > > On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <[email protected]> > wrote: > > > >> The question is now: Do we really intend to create the directory in > Lucene 5 ? What about opening an IndexReader on a non-existent directory on > a read-only filesystem? I know that Robert added this to make > path.getRealPath() to work correctly? > >> > >> I just want to discuss this before we release 5.0. To me it sounds > wrong to create the directory in the constructor... > >> > > > > Please dont call this a bug until you understand why the change was > > made. Please, read the behavior of getCanonicalPath and understand > > exactly why and how it fails: and its this nonexistent case. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
