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.
