[ 
https://issues.apache.org/jira/browse/LUCENE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649954#action_12649954
 ] 

Andrzej Bialecki  commented on LUCENE-1464:
-------------------------------------------

Ok, after reading LUCENE-773 I reluctantly agree. I think that my doubts are 
related to the fact that now we can get a valid instance of Directory, which 
points to an invalid filesystem path, one which perhaps cannot be created at 
all, and we are going to discover this only when opening IndexWriter with 
create=true flag. In all other situations we are going to get an IOException 
about the missing "segments" file, which may be misleading.

For this reason I thought it would be better to test the presence of the index 
path immediately, and create the directory if necessary in Directory only when 
it's really needed, i.e. when we intend to use Directory for writing. 
Essentially, I prefer to distinguish between read-only and read-write Directory 
on the API level of Directory.

Anyway, as I said, I'm fine with this patch.

> FSDirectory.getDirectory always creates index path
> --------------------------------------------------
>
>                 Key: LUCENE-1464
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1464
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 2.4, 2.9
>            Reporter: Andrzej Bialecki 
>            Assignee: Michael McCandless
>         Attachments: LUCENE-1464.patch
>
>
> This was reported to me as a Luke bug, but going deeper it proved to be a 
> non-intuitive (broken?) behavior of FSDirectory.
> If you use FSDirectory.getDirectory(File nonexistent) on a nonexistent path, 
> but one that is located under some existing parent path, then FSDirectory:174 
> uses file.mkdirs() to create this directory. One would expect a variant of 
> the method with a boolean flag to decide whether or not to create the output 
> path. However, the API with "create" flag is now deprecated, with a comment 
> that points to IndexWriter's "create" flag. This comment is misleading, 
> because the indicated path is created anyway in the file system just by 
> calling FSDirectory.getDirectory().
> I propose to do one of the following:
> * reinstate the variant of the method with "create" flag. In case if this 
> flag is false, and the index directory is missing, either return null or 
> throw an IOException,
> * keep the API as it is now, but either return null or throw IOException if 
> the index dir is missing. This breaks the backwards compatibility, because 
> now users are required to do file.mkdirs() themselves prior to calling 
> FSDirectory.getDirectory().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to