In the past we considered this ("mkdir when creating FSDir") a bug:
https://issues.apache.org/jira/browse/LUCENE-1464Mike McCandless http://blog.mikemccandless.com On Wed, Feb 4, 2015 at 4:03 AM, Uwe Schindler <[email protected]> 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 > [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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
