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

[Jim Gish]

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?

Thanks,
     Jim

BTW I was expecting that NotDirectoryException would be thrown. However, 
sun.nio.fs.UnixException does not translate an error code 20 
(UnixConstants.ENOTDIR) to NotDirectoryException, even though it could.  
Perhaps we should fix that, unless you see a reason not to. I'll check 
the history, bug reports, etc. and bring it up on nio-dev unless you 
know off the top of your head why we're not checking for ENOTDIR error code.


On 11/14/2012 06:08 AM, Alan Bateman wrote:
> On 13/11/2012 21:30, Jim Gish wrote:
>> Here's a new webrev with my latest changes for your reviewing 
>> pleasure :-)
>>
>> http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ 
>> <http://cr.openjdk.java.net/%7Ejgish/Bug6244047-FileHandler-CheckLockLocation/>
>>
>> Main changes:
>> - Using the file channel directly as suggested.
>> - Instead of checking up front for a valid directory I check the 
>> IOException on the channel open and process it accordingly. (BTW, I 
>> much prefer my previous proposed fix because I like to ensure 
>> pre-conditions for an operation are met prior to it rather than 
>> attempting the op, failing, and then recovering),
>> - Eliminated the stream, which really isn't needed, and just use the 
>> file channel
>>
>> Just for the purposes of my enlightenment, assuming this is what you 
>> were after (Jason & Alan), what was your issue with checking for a 
>> valid directory up-front?
>>
>> Thanks,
>>    Jim
> I get it now (I missed this on the first round), this code is using 
> lock files and not really using file-locking as intended.
>
> I think the FileChannel.open usage is fine, I'm just not sure about 
> the exception handling. For starters, FileSystemException is a super 
> type of AccessDeniedException and NoSuchFileSystem so I don't think 
> you need to catch them specifically. Would I be correct to say that 
> the only reason that you would have to recover and try the next file 
> is if the lock file exist? In that case then maybe it just needs to be:
>
> try {
>     lockFileChannel = FileChannel.open(...);
> } catch (FileAlreadyExistsException ignore) {
>     continue;
> }
>
> -Alan.
>
>
>
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com