java.nio.file.Files.isReadable() returns false on readable file

[Victor Ott]

Hello Alan,

thanks for your fast reply and for the clarification. I understand what the
issue is, and indeed, there probably is no simple solution for ACL
evaluation.

As I need to reliably determine if a file is readable, I followed the idea
from the thread I cited below, so I'm now using a FileChannel open/close to
determine if the file is readable:

    public static boolean isReadable(Path path) {
        try (FileChannel fc = FileChannel.open(path,
StandardOpenOption.READ)) {
            // NOP
        } catch (IOException e) {
            return false;
        }
        return true;
    }

Btw, this also improves the first call issue, as a plain timing shows (here
one worst case of ~2,2 seconds):

file: c:\temp\dummyfile.txt
freshly read: ABC
1342462181820
*    File.canRead():       true
1342462181820
*    IoUtils.isReadable(): true
1342462181820
*    Files.isReadable():   false
1342462184114


Best regards,
Victor



On Mon, Jul 16, 2012 at 6:26 PM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

>  On 16/07/2012 17:19, Victor Ott wrote:
>
> Hello,
>
> I've searched for similar issues and have found this thread int nio-dev
> mailing list: "java.nio.file.Files.isReadable() slow on Windows 7" (
> http://mail.openjdk.java.net/pipermail/nio-dev/2012-May/001666.html  or
> http://markmail.org/thread/ytjr6dwrxwxku2r4 ), but am asking this on
> nio-discuss because ... maybe I'm not seeing the obvious.
> Besides noticing that the first call to Files.isReadable() is indeed slow
> (only the first one, not subsequent calls), I have another issue:
> Files.isReadable() fails an a obviously readable file. See below my example
> code.
>
> Here the output:
> file: c:\temp\dummyfile.txt
> freshly read: ABC
> File.canRead():     true
> Files.isReadable(): false
>
> WinXP x32, JDK7u5 x32, NTFS file system. (And yes, I do have local admin
> rights).
>
> We have 7168172 open for this, sorry we don't have a solution for it yet.
> The reason for the issue is that the method tries to determine the
> effective access to the file and this is complex/expensive to do
> (File.canRead does not do this and so doesn't work correctly with ACLs on
> NTFS).
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20120716/ee3be0c1/attachment.html