[
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)
