xadisk
  1. xadisk
  2. XADISK-120

fileExists throws InsufficientPermissionOnFileException

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Works as designed
    • Affects Version/s: None
    • Fix Version/s: current
    • Component/s: None
    • Labels:
      None
    • Environment:

      Windows 7 64bit
      JDK 1.6.0_29

      Description

      fileExists sometimes thows InsufficientPermissionOnFileException instead of returning false.

      Suppose we have some directory structure with root directory <dataRoot> (which exiss).
      Then we check if directories <dataRoot>/dir3, <dataRoot>/dir3/subdir1 and <dataRoot>/dir3/subdir1/subdir2 exist (but they don't):

      File dir1 = new File(dataRoot, "dir3");
      File dir2 = new File(dir1, "subdir1");
      File dir3 = new File(dir2, "subdir2");

      session.fileExists(dir1); // works
      session.fileExists(dir2); // throws InsufficientPermissionOnFileException:
      session.fileExists(dir3); // works

      When fileExiss is invoked for <dataRoot>/dir3/subdir1 it throws InsufficientPermissionOnFileException

      org.xadisk.filesystem.exceptions.InsufficientPermissionOnFileException: Permission of type [READ_DIRECTORY] is needed over the file/directory with path [C:\Users\titmus\AppData\Local\Temp\junit283329822371778462\data\dir3] for the i/o operation to succeed.
      at org.xadisk.filesystem.NativeSession.checkPermission(NativeSession.java:1078)
      at org.xadisk.filesystem.NativeSession.fileExists(NativeSession.java:401)
      at org.xadisk.filesystem.NativeSession.fileExists(NativeSession.java:385)

        Activity

        Hide
        titmus added a comment -

        The fileExistsAndIsDirectory method behaves in the same way.

        Show
        titmus added a comment - The fileExistsAndIsDirectory method behaves in the same way.
        Hide
        Nitin Verma added a comment -

        All operations in XADiskBasicIOOperations are preceded by a permission check over the file/parent-file(directory). The fileExists operation is preceded by a read permission check over the parent directory. We call (in VirtualViewDirectory) Java File's canRead/canWrite methods without first checking for existence (this saves us an extra call to Java File's exists method), and these methods from Java File do not report any existence related exception - they simply say canRead/canWrite or not. This is the reason we cannot distinguish permission or existence issue.

        Leaving it as-designed for now, assuming a small compromise would be possible with the api users for the exception handling part. But anyone please feel free to comment back.

        Show
        Nitin Verma added a comment - All operations in XADiskBasicIOOperations are preceded by a permission check over the file/parent-file(directory). The fileExists operation is preceded by a read permission check over the parent directory. We call (in VirtualViewDirectory) Java File's canRead/canWrite methods without first checking for existence (this saves us an extra call to Java File's exists method), and these methods from Java File do not report any existence related exception - they simply say canRead/canWrite or not. This is the reason we cannot distinguish permission or existence issue. Leaving it as-designed for now, assuming a small compromise would be possible with the api users for the exception handling part. But anyone please feel free to comment back.
        Hide
        hell_keeper added a comment -

        Hi, I agree with you with the fact that a small compromise can be possible with the user of the API. However, about the semantic of the method, I think it’s a bad idea if a folder or a file does not exist to return an exception about the read/write authorization because its parent does not exist. I’m testing and using XADisk API to handle files/folders with path and it’s a little bit frustrating to don’t understand why we do not have the expected behavior when testing if a file exists because the some previous folders of the path have not be created (not because I have not managed it but because it can be possible in my workflow :/).

        What do you think about the semantic and the fact to force the user to handle an Illegitimate exception just to avoid to perform a File.exists ? Does the File.exists has huge drawback on performance ?

        Please let me know your point of view about that .

        Best regards.

        Show
        hell_keeper added a comment - Hi, I agree with you with the fact that a small compromise can be possible with the user of the API. However, about the semantic of the method, I think it’s a bad idea if a folder or a file does not exist to return an exception about the read/write authorization because its parent does not exist. I’m testing and using XADisk API to handle files/folders with path and it’s a little bit frustrating to don’t understand why we do not have the expected behavior when testing if a file exists because the some previous folders of the path have not be created (not because I have not managed it but because it can be possible in my workflow :/). What do you think about the semantic and the fact to force the user to handle an Illegitimate exception just to avoid to perform a File.exists ? Does the File.exists has huge drawback on performance ? Please let me know your point of view about that . Best regards.

          People

          • Assignee:
            Nitin Verma
            Reporter:
            titmus
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: