Return-Path: X-Original-To: apmail-commons-issues-archive@minotaur.apache.org Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2F07BDB11 for ; Sat, 6 Oct 2012 01:58:03 +0000 (UTC) Received: (qmail 91897 invoked by uid 500); 6 Oct 2012 01:58:02 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 91785 invoked by uid 500); 6 Oct 2012 01:58:02 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 91775 invoked by uid 99); 6 Oct 2012 01:58:02 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Oct 2012 01:58:02 +0000 Date: Sat, 6 Oct 2012 01:58:02 +0000 (UTC) From: "Dennis Zhu (JIRA)" To: issues@commons.apache.org Message-ID: <486846474.4260.1349488682825.JavaMail.jiratomcat@arcas> In-Reply-To: <1892138664.90363.1347925268919.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (VFS-437) [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 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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 (mockbuild@builder10.centos.org) (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