> On Feb 4, 2015, at 10:12, Uwe Schindler <[email protected]> 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 ?

Andi..

> 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 sentence.
> 
> Uwe
> 
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: [email protected]
> 
> 
>> -----Original Message-----
>> From: Robert Muir [mailto:[email protected]]
>> Sent: Wednesday, February 04, 2015 3:21 PM
>> To: [email protected]
>> Subject: Re: FSDirectory and creating directory
>> 
>>> On Wed, Feb 4, 2015 at 9:15 AM, Uwe Schindler <[email protected]> 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: [email protected] For additional
>> commands, e-mail: [email protected]
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to