RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist

Alan Bateman Alan.Bateman at oracle.com
Thu Nov 15 11:48:58 UTC 2012

On 14/11/2012 21:54, Jim Gish wrote:
> On 11/14/2012 04:38 PM, Alan Bateman wrote:
>> On 14/11/2012 20:56, Jim Gish wrote:
>>> Check out the latest, please -- 
>>> http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ 
>>> <http://cr.openjdk.java.net/%7Ejgish/Bug6244047-FileHandler-CheckLockLocation/> 
>>> -- If it's ok, please push it or let me know who to have do it?
>> I think it's okay except that you don't need to catch IOException, 
>> simply catching FileAlreadyExistsException exception should do it. If 
>> you agree then update the patch and I can push it for you.
> But of course.  Sorry I missed the obvious.  Just peeling the onion 
> when I could have taken a bite :-)  Fixed, and updated.
Good, it looks fine now.

> Exactly -- that's my point.  This is one of those cases.  You're 
> trying to create a new file in a directory, but the file you specified 
> isn't a directory - it's a plain file.  The error code coming back is 
> ENOTDIR and so what you get is the more general FileSystemException 
> with "Not a directory" as the error message, when in fact, we could 
> throw NotDirectoryException if we'd simply check for errno of ENOTDIR 
> in the first place along with the other checks being done in 
> UnixException translateToIOException(File,String).
This isn't an obvious as it might seem because having ENOTDIR always map 
to DirectoryNotEmptyException may cause that exception to be thrown in 
other cases too.  Additionally, this specific exception was intended for 
cases where you attempt to do something on a directory but it turns out 
the file is not a directory, this is subtly different to the case here. 
So we need to separate this one, I think the FileSystemException that 
you are seeing now is reasonable.


More information about the core-libs-dev mailing list