[
https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470857#comment-13470857
]
Dennis Zhu commented on VFS-437:
--------------------------------
I just tested again with my setup with your patch applied and the code seems to
work: if the link is circular, then we return it as imaginary and does not
allow the user to access it. Furthermore, I tested it on the case of Vol1 ->
... -> /Vol1 and ultimately VFS will evaluate through all the links and arrive
at the same /Vol1 and catch the imaginary file and refuse to access the link.
My setup was such that Vol1 will link to vol1, vol1 then links to vol3, then
vol3 ultimately links back to /Vol1, so Vol1 -> vol1 -> vol3 -> /Vol1.
Now, I am able to see a problem if I have this setup:
Vol1 -> Vol3
Vol3 -> Vol1
That WILL cause a StackOverFlowError. However, even though the user is allowed
to setup that link, the Linux file system itself refuses to evaluate those
links with the error "-bash: cd: Vol1: Too many levels of symbolic links".
As far as checking for circular links in doGetChildren(), I don't think there
is a need because before we ever hit the doGetChildren code, we'll always hit
the doGetType code first. Having a circular link check inside doGetChildren
would be redundant.
> [FTP] Program crashes when StackOverFlow Exception happens from pulling a
> softlinked directory that link to the directory that has the same name one
> level above
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: VFS-437
> URL: https://issues.apache.org/jira/browse/VFS-437
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Linux version 2.6.18-238.el5 ([email protected]) (gcc version
> 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
> Reporter: Jason
> Priority: Blocker
> Fix For: 2.1
>
> Attachments: VFS-437.diff, vfs-437-v2-gg.diff
>
>
> With the setting below, StackOverFlow exceptions occur and server crashes
> set the builder.setUserDirlsRoot (opt, true)
> Attept to pull with:
> ftp://root:password@ip:/Vol1
> Vol directory has the following info
> lrwxrwxrwx 1 root root 5 Oct 5 2007 Vol1 -> /Vol1
> When it tries to look for the parent of the Vol1, it goes back to the same
> Vol1, which causes a infinite loop that eventually creates stackoverflow
> exception.
> The problem is inside the doGetType() method in FtpFileObject
> @Override
> protected FileType doGetType()
> throws Exception
> {
> // VFS-210
> synchronized (getFileSystem())
> {
> if (this.fileInfo == null)
> {
> getInfo(false);
> }
> if (this.fileInfo == UNKNOWN)
> {
> return FileType.IMAGINARY;
> }
> else if (this.fileInfo.isDirectory())
> {
> return FileType.FOLDER;
> }
> else if (this.fileInfo.isFile())
> {
> return FileType.FILE;
> }
> else if (this.fileInfo.isSymbolicLink())
> {
> return getLinkDestination().getType();
> }
> }
> throw new FileSystemException("vfs.provider.ftp/get-type.error",
> getName());
> }
> It will keep hitting the "else if (this.fileinfo.isSymbolicLink())" condition
> and the fileinfo displayed is always the Vol1 under root directory.
> Exception is shown below
> java.lang.StackOverflowError
> at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
