[ https://issues.apache.org/jira/browse/SSHD-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369880#comment-16369880 ]
Goldstein Lyor commented on SSHD-730: ------------------------------------- Bottom line from the long :) comment - we should revise the _normalizePath_ code so that it is less aggressive in dealing with "." and ".." and the let the underlying {{FileSystem}} resolve the result (reminder: the {{FileSystem}} is the one obtained from the {{FileSystemFactory}} - so it can be anything we like). In other words, try and "compress" convoluted paths such as {{./a/b/./c/../d/../e}} to something more manageable while *preserving* leading dot (or dots). The same applies for symbolic links - normalize the result and delegate to whatever {{FileSystem}} implementation is currently provided to {{SftpSubsystem}} to deal with them. > Relative symbolic links with .. is not resolved properly by sftp readLink > ------------------------------------------------------------------------- > > Key: SSHD-730 > URL: https://issues.apache.org/jira/browse/SSHD-730 > Project: MINA SSHD > Issue Type: Bug > Affects Versions: 1.1.0, 1.2.0, 1.3.0 > Reporter: Lukas Waldmann > Assignee: Goldstein Lyor > Priority: Minor > > Using sftp to resolve symbolic links doesn't return proper resolution in case > symbolic link contains .. > Since version 1.1 the sendLink function of SftpSubsystem uses > normalizedPath = SelectorUtils.normalizePath(unixPath, "/"); > to normalize path > This function however return invalid path in case link contains ".." > So for example if link is "../test/file" than normalizePath returns > "test/file" which is invalid because in can not be resolved properly in the > context of the current directory which symbolic link is referring to. -- This message was sent by Atlassian JIRA (v7.6.3#76005)