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/
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
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
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
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
On 11/13/2012 07:08 AM, Alan Bateman wrote:
On 12/11/2012 23:22, Jim Gish wrote:
Which file(s) are you concerned about truncating/damaging? The code
I'm impacting is for creating a new lock file. Where is the
potential for truncating/damaging that you both are referring to?
Is this
Jim,
Looking at the webrev again I think I tricked myself into thinking that
'parentFile' was a file that could be opened with a stream when it actually is
a directory. I think the best fix would be to add a check in the catch block
(around line 432) and only continue if the directory of
On 11/13/2012 03:36 PM, Jason Mehrens wrote:
Jim,
Looking at the webrev again I think I tricked myself into thinking
that 'parentFile' was a file that could be opened with a stream when
it actually is a directory. I think the best fix would be to add
a check in the catch block (around line
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.
-
Which file(s) are you concerned about truncating/damaging? The code I'm
impacting is for creating a new lock file. Where is the potential for
truncating/damaging that you both are referring to?
Is this sufficient (plus the proper exception handling of course) ?
On 09/11/2012 22:41, Jason Mehrens wrote:
Jim,
You might just want to change the code to create and close a FileOutputStream
in a way that doesn't truncate or damage the target file. Or maybe use the NIO
file code if that is possible. See BUG ID 4420020.
Jason
I think so too. As it needs a
Please review
http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/
http://cr.openjdk.java.net/%7Ejgish/Bug6244047-FileHandler-CheckLockLocation/
This updates the logging FileHandler to actually check the directory
passed to it via the pattern to ensure that it exists
Jim,
You might just want to change the code to create and close a FileOutputStream
in a way that doesn't truncate or damage the target file. Or maybe use the NIO
file code if that is possible. See BUG ID 4420020.
Jason
Date: Fri, 9 Nov 2012 16:37:02 -0500
From: jim.g...@oracle.com
13 matches
Mail list logo
