You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Uwe Schindler <us...@apache.org> on 2015/02/04 10:03:40 UTC
FSDirectory and creating directory
Hi,
on the Lucene.NET mailing list there were some issues with porting over Lucene 4.8's FSDirectory class to .NET. In fact the following comment on a method caused confusion:
// returns the canonical version of the directory, creating it if it doesn't exist.
private static File getCanonicalPath(File file) throws IOException {
return new File(file.getCanonicalPath());
}
In fact, the comment is not correct (and the whole method is useless - one could call file.getCanonicalFile() to do the same. According to Javadocs and my tests, this method does *not* generate the directory. If the directory does not exists, it just returns a "synthetic" canonical name (modifying only "known" parts of the path). In fact we should maybe fix this comment and remove this method in 4.10.x (if we get a further bugfix release).
We also have a test that validates that a directory is not created by FSDirectory's ctor (a side effect of some IndexWriter test).
Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory CTOR with NIO.2:
protected FSDirectory(Path path, LockFactory lockFactory) throws IOException {
super(lockFactory);
Files.createDirectories(path); // create directory, if it doesn't exist
directory = path.toRealPath();
}
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...
Uwe
-----
Uwe Schindler
uschindler@apache.org
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: FSDirectory and creating directory
Posted by Uwe Schindler <us...@apache.org>.
Hi Mike,
This is why I ask here! So I think we should fix this before release of 5.0! Maybe Robert has an explanation why he does the createDirectories() on ctor.
In any case I will now commit the removal of the bogus comment in 4.10 branch.
Uwe
-----
Uwe Schindler
uschindler@apache.org
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Wednesday, February 04, 2015 10:07 AM
> To: Lucene/Solr dev
> Cc: dev@lucenenet.apache.org
> Subject: Re: FSDirectory and creating directory
>
> In the past we considered this ("mkdir when creating FSDir") a bug:
> https://issues.apache.org/jira/browse/LUCENE-1464
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
> wrote:
> > Hi,
> >
> > on the Lucene.NET mailing list there were some issues with porting over
> Lucene 4.8's FSDirectory class to .NET. In fact the following comment on a
> method caused confusion:
> >
> > // returns the canonical version of the directory, creating it if it doesn't
> exist.
> > private static File getCanonicalPath(File file) throws IOException {
> > return new File(file.getCanonicalPath());
> > }
> >
> > In fact, the comment is not correct (and the whole method is useless - one
> could call file.getCanonicalFile() to do the same. According to Javadocs and
> my tests, this method does *not* generate the directory. If the directory
> does not exists, it just returns a "synthetic" canonical name (modifying only
> "known" parts of the path). In fact we should maybe fix this comment and
> remove this method in 4.10.x (if we get a further bugfix release).
> >
> > We also have a test that validates that a directory is not created by
> FSDirectory's ctor (a side effect of some IndexWriter test).
> >
> > Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory
> CTOR with NIO.2:
> >
> > protected FSDirectory(Path path, LockFactory lockFactory) throws
> IOException {
> > super(lockFactory);
> > Files.createDirectories(path); // create directory, if it doesn't exist
> > directory = path.toRealPath();
> > }
> >
> > 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...
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > uschindler@apache.org
> > Apache Lucene PMC Member / Committer
> > Bremen, Germany
> > http://lucene.apache.org/
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
No, that wasn't a bug. What you guys did there was add locking bugs.
the canonical path of a non-existent directory can differ from an
existent one. So usage of getCanonicalPath here in lucene 4 is
_completely broken_ and so are lockprefixes and everything related to
them.
On Wed, Feb 4, 2015 at 4:06 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> In the past we considered this ("mkdir when creating FSDir") a bug:
> https://issues.apache.org/jira/browse/LUCENE-1464
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org> wrote:
>> Hi,
>>
>> on the Lucene.NET mailing list there were some issues with porting over Lucene 4.8's FSDirectory class to .NET. In fact the following comment on a method caused confusion:
>>
>> // returns the canonical version of the directory, creating it if it doesn't exist.
>> private static File getCanonicalPath(File file) throws IOException {
>> return new File(file.getCanonicalPath());
>> }
>>
>> In fact, the comment is not correct (and the whole method is useless - one could call file.getCanonicalFile() to do the same. According to Javadocs and my tests, this method does *not* generate the directory. If the directory does not exists, it just returns a "synthetic" canonical name (modifying only "known" parts of the path). In fact we should maybe fix this comment and remove this method in 4.10.x (if we get a further bugfix release).
>>
>> We also have a test that validates that a directory is not created by FSDirectory's ctor (a side effect of some IndexWriter test).
>>
>> Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory CTOR with NIO.2:
>>
>> protected FSDirectory(Path path, LockFactory lockFactory) throws IOException {
>> super(lockFactory);
>> Files.createDirectories(path); // create directory, if it doesn't exist
>> directory = path.toRealPath();
>> }
>>
>> 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...
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> uschindler@apache.org
>> Apache Lucene PMC Member / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
No, that wasn't a bug. What you guys did there was add locking bugs.
the canonical path of a non-existent directory can differ from an
existent one. So usage of getCanonicalPath here in lucene 4 is
_completely broken_ and so are lockprefixes and everything related to
them.
On Wed, Feb 4, 2015 at 4:06 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> In the past we considered this ("mkdir when creating FSDir") a bug:
> https://issues.apache.org/jira/browse/LUCENE-1464
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org> wrote:
>> Hi,
>>
>> on the Lucene.NET mailing list there were some issues with porting over Lucene 4.8's FSDirectory class to .NET. In fact the following comment on a method caused confusion:
>>
>> // returns the canonical version of the directory, creating it if it doesn't exist.
>> private static File getCanonicalPath(File file) throws IOException {
>> return new File(file.getCanonicalPath());
>> }
>>
>> In fact, the comment is not correct (and the whole method is useless - one could call file.getCanonicalFile() to do the same. According to Javadocs and my tests, this method does *not* generate the directory. If the directory does not exists, it just returns a "synthetic" canonical name (modifying only "known" parts of the path). In fact we should maybe fix this comment and remove this method in 4.10.x (if we get a further bugfix release).
>>
>> We also have a test that validates that a directory is not created by FSDirectory's ctor (a side effect of some IndexWriter test).
>>
>> Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory CTOR with NIO.2:
>>
>> protected FSDirectory(Path path, LockFactory lockFactory) throws IOException {
>> super(lockFactory);
>> Files.createDirectories(path); // create directory, if it doesn't exist
>> directory = path.toRealPath();
>> }
>>
>> 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...
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> uschindler@apache.org
>> Apache Lucene PMC Member / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
RE: FSDirectory and creating directory
Posted by Uwe Schindler <us...@apache.org>.
Hi Mike,
This is why I ask here! So I think we should fix this before release of 5.0! Maybe Robert has an explanation why he does the createDirectories() on ctor.
In any case I will now commit the removal of the bogus comment in 4.10 branch.
Uwe
-----
Uwe Schindler
uschindler@apache.org
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Wednesday, February 04, 2015 10:07 AM
> To: Lucene/Solr dev
> Cc: dev@lucenenet.apache.org
> Subject: Re: FSDirectory and creating directory
>
> In the past we considered this ("mkdir when creating FSDir") a bug:
> https://issues.apache.org/jira/browse/LUCENE-1464
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
> wrote:
> > Hi,
> >
> > on the Lucene.NET mailing list there were some issues with porting over
> Lucene 4.8's FSDirectory class to .NET. In fact the following comment on a
> method caused confusion:
> >
> > // returns the canonical version of the directory, creating it if it doesn't
> exist.
> > private static File getCanonicalPath(File file) throws IOException {
> > return new File(file.getCanonicalPath());
> > }
> >
> > In fact, the comment is not correct (and the whole method is useless - one
> could call file.getCanonicalFile() to do the same. According to Javadocs and
> my tests, this method does *not* generate the directory. If the directory
> does not exists, it just returns a "synthetic" canonical name (modifying only
> "known" parts of the path). In fact we should maybe fix this comment and
> remove this method in 4.10.x (if we get a further bugfix release).
> >
> > We also have a test that validates that a directory is not created by
> FSDirectory's ctor (a side effect of some IndexWriter test).
> >
> > Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory
> CTOR with NIO.2:
> >
> > protected FSDirectory(Path path, LockFactory lockFactory) throws
> IOException {
> > super(lockFactory);
> > Files.createDirectories(path); // create directory, if it doesn't exist
> > directory = path.toRealPath();
> > }
> >
> > 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...
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > uschindler@apache.org
> > Apache Lucene PMC Member / Committer
> > Bremen, Germany
> > http://lucene.apache.org/
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Wed, Feb 4, 2015 at 4:44 AM, Itamar Syn-Hershko <it...@code972.com> wrote:
> Mike I did promise to find bugs!
Thank you!
Mike McCandless
http://blog.mikemccandless.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: FSDirectory and creating directory
Posted by Uwe Schindler <uw...@thetaphi.de>.
You found a possible bug in coming Lucene 5.0 without actually using it! J
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
<http://www.thetaphi.de/> http://www.thetaphi.de
eMail: uwe@thetaphi.de
From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On Behalf Of Itamar Syn-Hershko
Sent: Wednesday, February 04, 2015 10:44 AM
To: dev@lucene.apache.org
Subject: Re: FSDirectory and creating directory
Thanks guys, we will mimic the current behavior and ignore the comment. Mike I did promise to find bugs!
--
Itamar Syn-Hershko
http://code972.com <http://code972.com/> | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Lucene.NET committer and PMC member
On Wed, Feb 4, 2015 at 11:20 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
Hi Mike,
This is why I ask here! So I think we should fix this before release of 5.0! Maybe Robert has an explanation why he does the createDirectories() on ctor.
In any case I will now commit the removal of the bogus comment in 4.10 branch.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Wednesday, February 04, 2015 10:07 AM
> To: Lucene/Solr dev
> Cc: dev@lucenenet.apache.org
> Subject: Re: FSDirectory and creating directory
>
> In the past we considered this ("mkdir when creating FSDir") a bug:
> https://issues.apache.org/jira/browse/LUCENE-1464
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
> wrote:
> > Hi,
> >
> > on the Lucene.NET mailing list there were some issues with porting over
> Lucene 4.8's FSDirectory class to .NET. In fact the following comment on a
> method caused confusion:
> >
> > // returns the canonical version of the directory, creating it if it doesn't
> exist.
> > private static File getCanonicalPath(File file) throws IOException {
> > return new File(file.getCanonicalPath());
> > }
> >
> > In fact, the comment is not correct (and the whole method is useless - one
> could call file.getCanonicalFile() to do the same. According to Javadocs and
> my tests, this method does *not* generate the directory. If the directory
> does not exists, it just returns a "synthetic" canonical name (modifying only
> "known" parts of the path). In fact we should maybe fix this comment and
> remove this method in 4.10.x (if we get a further bugfix release).
> >
> > We also have a test that validates that a directory is not created by
> FSDirectory's ctor (a side effect of some IndexWriter test).
> >
> > Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory
> CTOR with NIO.2:
> >
> > protected FSDirectory(Path path, LockFactory lockFactory) throws
> IOException {
> > super(lockFactory);
> > Files.createDirectories(path); // create directory, if it doesn't exist
> > directory = path.toRealPath();
> > }
> >
> > 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...
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > uschindler@apache.org
> > Apache Lucene PMC Member / Committer
> > Bremen, Germany
> > http://lucene.apache.org/
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Itamar Syn-Hershko <it...@code972.com>.
Thanks guys, we will mimic the current behavior and ignore the comment.
Mike I did promise to find bugs!
--
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 11:20 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi Mike,
>
> This is why I ask here! So I think we should fix this before release of
> 5.0! Maybe Robert has an explanation why he does the createDirectories() on
> ctor.
> In any case I will now commit the removal of the bogus comment in 4.10
> branch.
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Michael McCandless [mailto:lucene@mikemccandless.com]
> > Sent: Wednesday, February 04, 2015 10:07 AM
> > To: Lucene/Solr dev
> > Cc: dev@lucenenet.apache.org
> > Subject: Re: FSDirectory and creating directory
> >
> > In the past we considered this ("mkdir when creating FSDir") a bug:
> > https://issues.apache.org/jira/browse/LUCENE-1464
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
> > wrote:
> > > Hi,
> > >
> > > on the Lucene.NET mailing list there were some issues with porting over
> > Lucene 4.8's FSDirectory class to .NET. In fact the following comment on
> a
> > method caused confusion:
> > >
> > > // returns the canonical version of the directory, creating it if it
> doesn't
> > exist.
> > > private static File getCanonicalPath(File file) throws IOException {
> > > return new File(file.getCanonicalPath());
> > > }
> > >
> > > In fact, the comment is not correct (and the whole method is useless -
> one
> > could call file.getCanonicalFile() to do the same. According to Javadocs
> and
> > my tests, this method does *not* generate the directory. If the directory
> > does not exists, it just returns a "synthetic" canonical name (modifying
> only
> > "known" parts of the path). In fact we should maybe fix this comment and
> > remove this method in 4.10.x (if we get a further bugfix release).
> > >
> > > We also have a test that validates that a directory is not created by
> > FSDirectory's ctor (a side effect of some IndexWriter test).
> > >
> > > Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory
> > CTOR with NIO.2:
> > >
> > > protected FSDirectory(Path path, LockFactory lockFactory) throws
> > IOException {
> > > super(lockFactory);
> > > Files.createDirectories(path); // create directory, if it doesn't
> exist
> > > directory = path.toRealPath();
> > > }
> > >
> > > 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...
> > >
> > > Uwe
> > >
> > > -----
> > > Uwe Schindler
> > > uschindler@apache.org
> > > Apache Lucene PMC Member / Committer
> > > Bremen, Germany
> > > http://lucene.apache.org/
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > > additional commands, e-mail: dev-help@lucene.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> > commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
RE: FSDirectory and creating directory
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi Mike,
This is why I ask here! So I think we should fix this before release of 5.0! Maybe Robert has an explanation why he does the createDirectories() on ctor.
In any case I will now commit the removal of the bogus comment in 4.10 branch.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Wednesday, February 04, 2015 10:07 AM
> To: Lucene/Solr dev
> Cc: dev@lucenenet.apache.org
> Subject: Re: FSDirectory and creating directory
>
> In the past we considered this ("mkdir when creating FSDir") a bug:
> https://issues.apache.org/jira/browse/LUCENE-1464
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
> wrote:
> > Hi,
> >
> > on the Lucene.NET mailing list there were some issues with porting over
> Lucene 4.8's FSDirectory class to .NET. In fact the following comment on a
> method caused confusion:
> >
> > // returns the canonical version of the directory, creating it if it doesn't
> exist.
> > private static File getCanonicalPath(File file) throws IOException {
> > return new File(file.getCanonicalPath());
> > }
> >
> > In fact, the comment is not correct (and the whole method is useless - one
> could call file.getCanonicalFile() to do the same. According to Javadocs and
> my tests, this method does *not* generate the directory. If the directory
> does not exists, it just returns a "synthetic" canonical name (modifying only
> "known" parts of the path). In fact we should maybe fix this comment and
> remove this method in 4.10.x (if we get a further bugfix release).
> >
> > We also have a test that validates that a directory is not created by
> FSDirectory's ctor (a side effect of some IndexWriter test).
> >
> > Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory
> CTOR with NIO.2:
> >
> > protected FSDirectory(Path path, LockFactory lockFactory) throws
> IOException {
> > super(lockFactory);
> > Files.createDirectories(path); // create directory, if it doesn't exist
> > directory = path.toRealPath();
> > }
> >
> > 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...
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > uschindler@apache.org
> > Apache Lucene PMC Member / Committer
> > Bremen, Germany
> > http://lucene.apache.org/
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Michael McCandless <lu...@mikemccandless.com>.
In the past we considered this ("mkdir when creating FSDir") a bug:
https://issues.apache.org/jira/browse/LUCENE-1464
Mike McCandless
http://blog.mikemccandless.com
On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org> wrote:
> Hi,
>
> on the Lucene.NET mailing list there were some issues with porting over Lucene 4.8's FSDirectory class to .NET. In fact the following comment on a method caused confusion:
>
> // returns the canonical version of the directory, creating it if it doesn't exist.
> private static File getCanonicalPath(File file) throws IOException {
> return new File(file.getCanonicalPath());
> }
>
> In fact, the comment is not correct (and the whole method is useless - one could call file.getCanonicalFile() to do the same. According to Javadocs and my tests, this method does *not* generate the directory. If the directory does not exists, it just returns a "synthetic" canonical name (modifying only "known" parts of the path). In fact we should maybe fix this comment and remove this method in 4.10.x (if we get a further bugfix release).
>
> We also have a test that validates that a directory is not created by FSDirectory's ctor (a side effect of some IndexWriter test).
>
> Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory CTOR with NIO.2:
>
> protected FSDirectory(Path path, LockFactory lockFactory) throws IOException {
> super(lockFactory);
> Files.createDirectories(path); // create directory, if it doesn't exist
> directory = path.toRealPath();
> }
>
> 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...
>
> Uwe
>
> -----
> Uwe Schindler
> uschindler@apache.org
> Apache Lucene PMC Member / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
Re: FSDirectory and creating directory
Posted by Michael McCandless <lu...@mikemccandless.com>.
In the past we considered this ("mkdir when creating FSDir") a bug:
https://issues.apache.org/jira/browse/LUCENE-1464
Mike McCandless
http://blog.mikemccandless.com
On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org> wrote:
> Hi,
>
> on the Lucene.NET mailing list there were some issues with porting over Lucene 4.8's FSDirectory class to .NET. In fact the following comment on a method caused confusion:
>
> // returns the canonical version of the directory, creating it if it doesn't exist.
> private static File getCanonicalPath(File file) throws IOException {
> return new File(file.getCanonicalPath());
> }
>
> In fact, the comment is not correct (and the whole method is useless - one could call file.getCanonicalFile() to do the same. According to Javadocs and my tests, this method does *not* generate the directory. If the directory does not exists, it just returns a "synthetic" canonical name (modifying only "known" parts of the path). In fact we should maybe fix this comment and remove this method in 4.10.x (if we get a further bugfix release).
>
> We also have a test that validates that a directory is not created by FSDirectory's ctor (a side effect of some IndexWriter test).
>
> Nevertheless, in Lucene 5 we changed the behavior of the FSDirectory CTOR with NIO.2:
>
> protected FSDirectory(Path path, LockFactory lockFactory) throws IOException {
> super(lockFactory);
> Files.createDirectories(path); // create directory, if it doesn't exist
> directory = path.toRealPath();
> }
>
> 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...
>
> Uwe
>
> -----
> Uwe Schindler
> uschindler@apache.org
> Apache Lucene PMC Member / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: FSDirectory and creating directory
Posted by Uwe Schindler <uw...@thetaphi.de>.
> On Wed, Feb 4, 2015 at 1:12 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> > Hi Robert,
> >
> > I am fine with any of your comments. We can move this issue to later
> releases, I just want that FSDirectory and its subclasses to document that
> they create the directory on its ctor if it does not yet exist. Please understand
> that I want to figure out if this could cause "human" issues, because I know
> people are always complaining about this shit. And I also wanted to be sure
> this causes no problems with read-only filesystems. People will for sure
> complain if they just want to open an indexreader and suddenly the
> FSDirectory complains about "I cannot write" instead of "Directory does not
> exist". I understand the reason behind this change: we want the "real"
> (canonical path), so NativeFSLockingFactory's stupid internal Set<Path>
> works correctly. No worry, I don’t want to change that for 5.0 - only
> document it! But we can think in later Lucene releases to go back to not
> creating the directory on front under read-only conditions (opening an
> IndexReader).
> >
> > Should I add those Javadocs, costs me not much, I just wanted to check this
> out before? In fact I would move the comment you added to the Javadocs of
> ctor and open() with an additional sentence.
>
> I don't mind if you change the javadocs, or handle exception from
> Files.createDirectories() differently (e.g. in case creation fails).
>
> Just remember, people will for sure complain if they just want to open an
> indexwriter and make a new index and suddenly FSDirectory complains
> about "Directory does not exist" instead of "I cannot write"
>
> :)
I will just change the Javadocs, so nobody can complain about that.
I also removed the bogus comment in 4.10 - which claimed the opposite what really happened. This caused most trouble, because the Lucene.NET people did not understand what was going wrong there and they tried to implement what the comment said. And to me it was also a "WTF?" issue :-)
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Feb 4, 2015 at 1:12 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi Robert,
>
> I am fine with any of your comments. We can move this issue to later releases, I just want that FSDirectory and its subclasses to document that they create the directory on its ctor if it does not yet exist. Please understand that I want to figure out if this could cause "human" issues, because I know people are always complaining about this shit. And I also wanted to be sure this causes no problems with read-only filesystems. People will for sure complain if they just want to open an indexreader and suddenly the FSDirectory complains about "I cannot write" instead of "Directory does not exist". I understand the reason behind this change: we want the "real" (canonical path), so NativeFSLockingFactory's stupid internal Set<Path> works correctly. No worry, I don’t want to change that for 5.0 - only document it! But we can think in later Lucene releases to go back to not creating the directory on front under read-only conditions (opening an IndexReader).
>
> Should I add those Javadocs, costs me not much, I just wanted to check this out before? In fact I would move the comment you added to the Javadocs of ctor and open() with an additional sentence.
I don't mind if you change the javadocs, or handle exception from
Files.createDirectories() differently (e.g. in case creation fails).
Just remember, people will for sure complain if they just want to open
an indexwriter and make a new index and suddenly FSDirectory complains
about "Directory does not exist" instead of "I cannot write"
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Andi Vajda <va...@osafoundation.org>.
> On Feb 4, 2015, at 10:12, Uwe Schindler <uw...@thetaphi.de> wrote:
>
> Hi Robert,
>
> I am fine with any of your comments. We can move this issue to later releases, I just want that FSDirectory and its subclasses to document that they create the directory on its ctor if it does not yet exist. Please understand that I want to figure out if this could cause "human" issues, because I know people are always complaining about this shit. And I also wanted to be sure this causes no problems with read-only filesystems. People will for sure complain if they just want to open an indexreader and suddenly the FSDirectory complains about "I cannot write" instead of "Directory does not exist". I understand the reason behind this change: we want the "real" (canonical path), so NativeFSLockingFactory's stupid
Maybe I'm missing some context here but if the file system is read-only, why is the locking stuff even getting involved ?
Andi..
> internal Set<Path> works correctly. No worry, I don’t want to change that for 5.0 - only document it! But we can think in later Lucene releases to go back to not creating the directory on front under read-only conditions (opening an IndexReader).
>
> Should I add those Javadocs, costs me not much, I just wanted to check this out before? In fact I would move the comment you added to the Javadocs of ctor and open() with an additional sentence.
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Robert Muir [mailto:rcmuir@gmail.com]
>> Sent: Wednesday, February 04, 2015 3:21 PM
>> To: dev@lucene.apache.org
>> Subject: Re: FSDirectory and creating directory
>>
>>> On Wed, Feb 4, 2015 at 9:15 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>>> I have no idea what happens if you call Files.createDirectories() on a read-
>> only file system if all directory components already exist (it should be a no-
>> op, but who knows).
>>>
>>
>> Why do you respond like this Uwe? Its clear what it does: it does what the
>> javadocs claim it does, or its a bug in the JDK.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: FSDirectory and creating directory
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi Robert,
I am fine with any of your comments. We can move this issue to later releases, I just want that FSDirectory and its subclasses to document that they create the directory on its ctor if it does not yet exist. Please understand that I want to figure out if this could cause "human" issues, because I know people are always complaining about this shit. And I also wanted to be sure this causes no problems with read-only filesystems. People will for sure complain if they just want to open an indexreader and suddenly the FSDirectory complains about "I cannot write" instead of "Directory does not exist". I understand the reason behind this change: we want the "real" (canonical path), so NativeFSLockingFactory's stupid internal Set<Path> works correctly. No worry, I don’t want to change that for 5.0 - only document it! But we can think in later Lucene releases to go back to not creating the directory on front under read-only conditions (opening an IndexReader).
Should I add those Javadocs, costs me not much, I just wanted to check this out before? In fact I would move the comment you added to the Javadocs of ctor and open() with an additional sentence.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Wednesday, February 04, 2015 3:21 PM
> To: dev@lucene.apache.org
> Subject: Re: FSDirectory and creating directory
>
> On Wed, Feb 4, 2015 at 9:15 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> > I have no idea what happens if you call Files.createDirectories() on a read-
> only file system if all directory components already exist (it should be a no-
> op, but who knows).
> >
>
> Why do you respond like this Uwe? Its clear what it does: it does what the
> javadocs claim it does, or its a bug in the JDK.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Feb 4, 2015 at 9:15 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> I have no idea what happens if you call Files.createDirectories() on a read-only file system if all directory components already exist (it should be a no-op, but who knows).
>
Why do you respond like this Uwe? Its clear what it does: it does what
the javadocs claim it does, or its a bug in the JDK.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: FSDirectory and creating directory
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
I said "possible bug" - and because of this I wanted to start a discussion. In fact, I am fine with this change if it is documented that creating a FSDirectory instance implicitely creates the directory - otherwise we are breaking https://issues.apache.org/jira/browse/LUCENE-1464 again.
To me I am not happy with this change, because it's wrong to me, if you just open an IndexReader (e.g., on a read-only filesystem) and it will try to create the directory. Can we be sure that this will not break if FileSystem is read-only (like CD-ROM). I have no idea what happens if you call Files.createDirectories() on a read-only file system if all directory components already exist (it should be a no-op, but who knows).
I was already thinking about optionally allow to open FSDirectory only for read, so it will fails early if dir does not already exist (openOutput would of course also fail, but that’s just on top of that). I have not yet a strong opinion.
So at least, please document this in FSDirectory and its subclasses that a call to open() or calling a ctor actually creates the directory!
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Wednesday, February 04, 2015 1:44 PM
> To: dev@lucene.apache.org
> Cc: dev@lucenenet.apache.org
> Subject: Re: FSDirectory and creating directory
>
> On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
> 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: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
Please read File.getCanonicalPath javadocs. As i said, the canonical
path for a nonexistent file can differ from an existent one.
So you cannot lock the object. it is the same problem as trying to
delete the write.lock file, its not safe.
On Wed, Feb 4, 2015 at 8:18 AM, Itamar Syn-Hershko <it...@code972.com> wrote:
> 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 <rc...@gmail.com> 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 <rc...@gmail.com> wrote:
>> > On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
>> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
Please read File.getCanonicalPath javadocs. As i said, the canonical
path for a nonexistent file can differ from an existent one.
So you cannot lock the object. it is the same problem as trying to
delete the write.lock file, its not safe.
On Wed, Feb 4, 2015 at 8:18 AM, Itamar Syn-Hershko <it...@code972.com> wrote:
> 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 <rc...@gmail.com> 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 <rc...@gmail.com> wrote:
>> > On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
>> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: FSDirectory and creating directory
Posted by Itamar Syn-Hershko <it...@code972.com>.
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 <rc...@gmail.com> 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 <rc...@gmail.com> wrote:
> > On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: FSDirectory and creating directory
Posted by Itamar Syn-Hershko <it...@code972.com>.
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 <rc...@gmail.com> 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 <rc...@gmail.com> wrote:
> > On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org>
> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
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 <rc...@gmail.com> wrote:
> On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org> 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.
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
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 <rc...@gmail.com> wrote:
> On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org> 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.
Re: FSDirectory and creating directory
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <us...@apache.org> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org