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
[email protected]
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
