Code Review Request: 7168172: (fs) Files.isReadable slow on Windows (original) (raw)
Alan Bateman Alan.Bateman at oracle.com
Thu Aug 23 12:07:23 PDT 2012
- Previous message: Code Review Request: 7168172: (fs) Files.isReadable slow on Windows
- Next message: Code Review Request: 7168172: (fs) Files.isReadable slow on Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 23/08/2012 00:33, Ulf Zibis wrote:
Am 22.08.2012 20:38, schrieb Kurchi Hazra:
However, it is faster to simply open the file being checked and close it. In the case of a directory then, a DirectoryStream can be opened and closed to check the same. I would rename checkReadAccess(WindowsPath file) to tryReadAccess(WindowsPath file) The API that the provider defines is checkAccess so I think it's okay to have this private specialized method for read be named checkReadAccess.
:
At least the boolean one could be saved easily and (modes.length == 0) is superfluous: public void checkAccess(Path obj, AccessMode... modes) throws IOException { AccessMode r = null; AccessMode w = null; AccessMode x = null; for (AccessMode mode: modes) { switch (mode) { case READ : r = READ; break; case WRITE : w = WRITE; break; case EXECUTE : x = EXECUTE; break; default: throw new AssertionError("Should not get here"); } } WindowsPath file = WindowsPath.toWindowsPath(obj); // special-case read access to avoid needing to determine effective // access to file if (w == null && x == null) { tryReadAccess(file); return; } You're right that the modes.length == 0 check could be skipped and then it becomes "if (!w && !x) { ... }". I'll leave it to Kurchi as to whether she wants to change this. I'm okay either way.
-Alan
- Previous message: Code Review Request: 7168172: (fs) Files.isReadable slow on Windows
- Next message: Code Review Request: 7168172: (fs) Files.isReadable slow on Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]