lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: FSDirectory and creating directory
Date Wed, 04 Feb 2015 19:26:41 GMT

> On Feb 4, 2015, at 10:12, Uwe Schindler <> wrote:
> Hi Robert,
> I am fine with any of your comments. We can move this issue to later releases, I just
want that FSDirectory and its subclasses to document that they create the directory on its
ctor if it does not yet exist. Please understand that I want to figure out if this could cause
"human" issues, because I know people are always complaining about this shit. And I also wanted
to be sure this causes no problems with read-only filesystems. People will for sure complain
if they just want to open an indexreader and suddenly the FSDirectory complains about "I cannot
write" instead of "Directory does not exist". I understand the reason behind this change:
we want the "real" (canonical path), so NativeFSLockingFactory's stupid

Maybe I'm missing some context here but if the file system is read-only, why is the locking
stuff even getting involved ?


> internal Set<Path> works correctly. No worry, I don’t want to change that for
5.0 - only document it! But we can think in later Lucene releases to go back to not creating
the directory on front under read-only conditions (opening an IndexReader).
> Should I add those Javadocs, costs me not much, I just wanted to check this out before?
 In fact I would move the comment you added to the Javadocs of ctor and open() with an additional
> Uwe
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> eMail:
>> -----Original Message-----
>> From: Robert Muir []
>> Sent: Wednesday, February 04, 2015 3:21 PM
>> To:
>> Subject: Re: FSDirectory and creating directory
>>> On Wed, Feb 4, 2015 at 9:15 AM, Uwe Schindler <> wrote:
>>> I have no idea what happens if you call Files.createDirectories() on a read-
>> only file system if all directory components already exist (it should be a no-
>> op, but who knows).
>> Why do you respond like this Uwe? Its clear what it does: it does what the
>> javadocs claim it does, or its a bug in the JDK.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: For additional
>> commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message