[
https://issues.apache.org/jira/browse/LUCENE-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370815#comment-15370815
]
Robert Muir commented on LUCENE-7375:
-------------------------------------
Well, another option is that NativeFSLockFactory etc already do their own
createDirectories + toRealPath (defensively). This came after the move to
nio.2, and maybe the one in FSDir can now just be removed.
This would require a bit of hair though: I think the only clean way to do it,
would be to say that the lockfactory is responsible for creating the directory
if it doesnt exist. That has implications for NO_LOCK_FACTORY and other crazy
options we have :)
> 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]
