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
<luc...@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 <uschind...@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
>> uschind...@apache.org
>> Apache Lucene PMC Member / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
