Uploaded image for project: 'MINA SSHD'
  1. MINA SSHD
  2. SSHD-1220

SFTP: too many LSTAT calls

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.7.0
    • 2.8.0
    • None

    Description

      While looking at an alternate solution for SSHD-1217 I noticed that the AbstractSftpSubsystemHelper makes several LSTAT calls for a single FileSystem.readAttributes() invocation.

      Basically it makes one LSTAT call per supported attributes view; only to collect the returned items then in one single map anyway.

      This doesn't make any sense. SFTP file attributes are a single, defined structure. If AbstractSftpSubsystemHelper.getAttributes() needs to collect all these different views (BasicFileAttributes, PosixFileAttributes, and so on) on these underlying SFTP attributes, then all these views should build upon the same single SftpClient.Attributes gotten exactly once.

      This could be solved with careful temporary caching of SFTP attributes on the SftpPath once read while in AbstractSftpSubsystemHelper.getAttributes() and clearing that cache at the end.

      The problem is more general, though. The code in several places makes up-front checks whether a file exists, is a directory, and so on. This is a questionable pattern anyway, since the result of a Files.exists() is outdated immediately; one cannot rely on the file being still there on the next access. With an SftpPath, this exists() call is an (L)STAT remote call getting the attributes. Now look at AbstractSftpSubsystemHelper.resolveFileAttributes: here getting the attributes themselves is so guarded, so it makes at least two LSTAT calls.

      This should also be improved.

      Attachments

        Issue Links

          Activity

            People

              twolf Thomas Wolf
              twolf Thomas Wolf
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 3h 10m
                  3h 10m