Goldstein Lyor commented on SSHD-814:

Not clear how you propose to enrich - please provide a description of the API 
you think is missing in the listener and how it can be used to provide the 
notifications you seek
in an elegant way
For my part I don't see that anything is missing - e.g.
download files that you do not have access to
     * Specified file / directory is being opened
     * @param session      The {@link ServerSession} through which the request 
was handled
     * @param remoteHandle The (opaque) assigned handle for the file / directory
     * @param localHandle  The associated file / directory {@link Handle}
     * @throws IOException If failed to handle the call
    public void opening(ServerSession session, String remoteHandle, Handle 
            throws IOException {
        Path path = localHandle.getFilePath();
        if (!okToAccess(path)) {
              throw new AccessDeniedException(....);

However, if you are talking about *client side* notification, then that is 
another issue altogether - the SFTP protocol does not provide standard 
indicators as to why an access request failed - we do out best to translate 
exceptions into relevant numerical codes, but that;s the best we can do:
    public static int resolveSubstatus(Throwable t) {
        if ((t instanceof NoSuchFileException) || (t instanceof 
FileNotFoundException)) {
            return SftpConstants.SSH_FX_NO_SUCH_FILE;
        } else if (t instanceof InvalidHandleException) {
            return SftpConstants.SSH_FX_INVALID_HANDLE;
        } else if (t instanceof FileAlreadyExistsException) {
            return SftpConstants.SSH_FX_FILE_ALREADY_EXISTS;
        } else if (t instanceof DirectoryNotEmptyException) {
            return SftpConstants.SSH_FX_DIR_NOT_EMPTY;
        } else if (t instanceof NotDirectoryException) {
            return SftpConstants.SSH_FX_NOT_A_DIRECTORY;
        } else if (t instanceof AccessDeniedException) {
            return SftpConstants.SSH_FX_PERMISSION_DENIED;
        } else if (t instanceof EOFException) {
            return SftpConstants.SSH_FX_EOF;
        } else if (t instanceof OverlappingFileLockException) {
            return SftpConstants.SSH_FX_LOCK_CONFLICT;
        } else if ((t instanceof UnsupportedOperationException)
                || (t instanceof UnknownServiceException)) {
            return SftpConstants.SSH_FX_OP_UNSUPPORTED;
        } else if (t instanceof InvalidPathException) {
            return SftpConstants.SSH_FX_INVALID_FILENAME;
        } else if (t instanceof IllegalArgumentException) {
            return SftpConstants.SSH_FX_INVALID_PARAMETER;
        } else if (t instanceof UserPrincipalNotFoundException) {
            return SftpConstants.SSH_FX_UNKNOWN_PRINCIPAL;
        } else if (t instanceof FileSystemLoopException) {
            return SftpConstants.SSH_FX_LINK_LOOP;
        } else if (t instanceof SftpException) {
            return ((SftpException) t).getStatus();
        } else {
            return SftpConstants.SSH_FX_FAILURE;

Note that you can provide your own {{SftpErrorStatusDataHandler}} that can do 
other things - but that's between you and your client - other (standard) 
clients might not "understand" what you did.

> enrich the SftpEventListener
> ----------------------------
>                 Key: SSHD-814
>                 URL: https://issues.apache.org/jira/browse/SSHD-814
>             Project: MINA SSHD
>          Issue Type: Improvement
>    Affects Versions: 1.7.0
>            Reporter: Zhenliang Su
>            Priority: Minor
>              Labels: EventListener, sftp
> In practice, I found that, the callback function provided by 
> SftpEventListener is not enough.  For example, the following situation is not 
> easy to be notified in a elegant way:
> {code:java}
> download files that you do not have access to
> download a file that no longer exists
> upload files to a directory without permissions
> create a new file in a directory that you do not have access to
> download or upload a file complete
> upload a zero size file
> ...{code}

This message was sent by Atlassian JIRA

Reply via email to