[
https://issues.apache.org/jira/browse/LUCENE-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370826#comment-15370826
]
Robert Muir commented on LUCENE-7375:
-------------------------------------
Also, think about any external use of `getDirectory()` and so on (this is even
used by toString). If someone calls this method, e.g. to key into a map of
their own, we've brought the old java.io.File trap back :)
So the Files.createDirectories isn't useless in that sense either, it returns
{{toRealPath}} today, which means such traps are impossible.
> Can we allow FSDirectory subclasses to customize whether the ctor does a
> mkdir?
> -------------------------------------------------------------------------------
>
> Key: LUCENE-7375
> URL: https://issues.apache.org/jira/browse/LUCENE-7375
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
>
> Today, just instantiating an {{FSDirectory}} always brings the directory into
> existence, even if you will do no writes ({{createOutput}}).
> We have gone back and forth on this, over the ages. E.g. see LUCENE-16 (only
> 2 digits there!!), LUCENE-773 (only 3 digits there!!), LUCENE-1464. At one
> point we created the directory lazily, on the first write ({{createOutput}})
> attempt, but now we always create it when you instantiate {{FSDirectory}}.
> This causes some hassle for consumers, e.g. in
> https://github.com/elastic/elasticsearch/pull/19338 ES is forking
> {{SimpleFSDirectory}} in order to have a read-only directory impl.
> Maybe we can do the {{Files.createDirectories}} in protected method that a
> subclass could override?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
