[jira] [Commented] (VFS-438) Please promote vfs-smb currently in the sandbox
[ https://issues.apache.org/jira/browse/VFS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230251#comment-14230251 ] Dan Tran commented on VFS-438: -- so this request is valid if vfs-smb's pom.xml has jcifs as optional? Please promote vfs-smb currently in the sandbox --- Key: VFS-438 URL: https://issues.apache.org/jira/browse/VFS-438 Project: Commons VFS Issue Type: New Feature Affects Versions: 2.0 Environment: windows/unix Reporter: Dan Tran Fix For: 2.1 Current smb provider in the sandbox is mature enough to proceed with promotion out of sandbox for general use. Detail discussion is here http://apache-commons.680414.n4.nabble.com/Promote-vfs-cift-out-of-sandbox-td4636519.html The sandbox also tests hookup to current test suite, all we need is to provide a external URI using VFS test suite instructions. There are currently 2 classloader specific failures Tests in error: testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): code.ClassToLoad testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): code.sealed.AnotherClass Tests run: 1745, Failures: 0, Errors: 2, Skipped: 0 require cifs 1.3.17 with one line change at SmbFileObject.java line number 227 to if (e.getNtStatus() == SmbException.NT_STATUS_NO_SUCH_FILE) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-438) Please promote vfs-smb currently in the sandbox
[ https://issues.apache.org/jira/browse/VFS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230929#comment-14230929 ] Dan Tran commented on VFS-438: -- The behavior you see is correction since you have comons-io as direct dependency of 4.12 junit. However, the user of commons-io will not see junit 4.12 download. The vfs-smb case, we can have jcift as optional dep, and the user of vfs-smb will never see jcif download to his/her local repo Please promote vfs-smb currently in the sandbox --- Key: VFS-438 URL: https://issues.apache.org/jira/browse/VFS-438 Project: Commons VFS Issue Type: New Feature Affects Versions: 2.0 Environment: windows/unix Reporter: Dan Tran Fix For: 2.1 Current smb provider in the sandbox is mature enough to proceed with promotion out of sandbox for general use. Detail discussion is here http://apache-commons.680414.n4.nabble.com/Promote-vfs-cift-out-of-sandbox-td4636519.html The sandbox also tests hookup to current test suite, all we need is to provide a external URI using VFS test suite instructions. There are currently 2 classloader specific failures Tests in error: testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): code.ClassToLoad testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): code.sealed.AnotherClass Tests run: 1745, Failures: 0, Errors: 2, Skipped: 0 require cifs 1.3.17 with one line change at SmbFileObject.java line number 227 to if (e.getNtStatus() == SmbException.NT_STATUS_NO_SUCH_FILE) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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
[
https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Tran updated VFS-437:
-
Attachment: VFS-437.diff
Proposed solution ( from Dennis )
[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 (mockbu...@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
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 root5 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
[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
[
https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468041#comment-13468041
]
Dan Tran commented on VFS-437:
--
Hi Gary,
Dennis, Jason, and I work on the same team. Other way to reproduce this issue
is
1. use anonymous account on a linux ftp server
2. On your anonymous workspace create a symlink ( Vol1 to /Vol1 ). The ftp'ls
command should show
ftp ls -al
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxr-xr-x4 004096 Oct 02 19:02 .
drwxr-xr-x4 004096 Oct 02 19:02 ..
lrwxrwxrwx1 00 5 Oct 02 19:02 Vol1 - /Vol1
drwxr-xr-x2 004096 Sep 03 2009 pub
-rw-r--r--1 00 224 Nov 09 2004 welcome.msg
226 Directory send OK.
ftp:385 bytes received in 0.00Seconds 385000.00Kbytes/sec.
3. Use vfs-maven-plugin to issue the following command ( provided that you
have access to codehaus's snapshot repository
mvn vfs:list -DsourceId=ftp.anonymous -Dsource=ftp://your.ftp.host/Vol1
This is very edgecase, however, it crashes our server application.
[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 (mockbu...@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
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 root5 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
[jira] [Created] (VFS-438) Please promote vfs-smb currently in the sandbox
Dan Tran created VFS-438: Summary: Please promote vfs-smb currently in the sandbox Key: VFS-438 URL: https://issues.apache.org/jira/browse/VFS-438 Project: Commons VFS Issue Type: New Feature Affects Versions: 2.0 Environment: windows/unix Reporter: Dan Tran Fix For: 2.1 Current smb provider in the sandbox is mature enough to proceed with promotion out of sandbox for general use. Detail discussion is here http://apache-commons.680414.n4.nabble.com/Promote-vfs-cift-out-of-sandbox-td4636519.html The sandbox also tests hookup to current test suite, all we need is to provide a external URI using VFS test suite instructions. There are currently 2 classloader specific failures Tests in error: testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): code.ClassToLoad testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): code.sealed.AnotherClass Tests run: 1745, Failures: 0, Errors: 2, Skipped: 0 require cifs 1.3.17 with one line change at SmbFileObject.java line number 227 to if (e.getNtStatus() == SmbException.NT_STATUS_NO_SUCH_FILE) -- 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
[jira] [Comment Edited] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13287147#comment-13287147 ] Dan Tran edited comment on VFS-180 at 6/10/12 11:14 PM: Any chance this get committed to VFS 2.1-SNAPSHOT soon? Thanks was (Author: danttran): will this get ported to VFS2? Support HTTPS / SSL for Webdav -- Key: VFS-180 URL: https://issues.apache.org/jira/browse/VFS-180 Project: Commons VFS Issue Type: New Feature Affects Versions: 1.0, 1.1 Reporter: Werner Mueller Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, patch_180_vfs2.txt, patch_180_vfs2.txt The Slide Webdav lib supports encrypted HTTPS connections. So it should be possible to add https support to vfs too. currently the webdav provider creates http urls (in WebdavClientFactory.java). maybe some provider like 'webdavs' could be added to switch to HttpsUrl. regards werner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13287147#comment-13287147 ] Dan Tran commented on VFS-180: -- will this get ported to VFS2? Support HTTPS / SSL for Webdav -- Key: VFS-180 URL: https://issues.apache.org/jira/browse/VFS-180 Project: Commons VFS Issue Type: New Feature Affects Versions: 1.0, 1.1 Reporter: Werner Mueller Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, patch_180_vfs2.txt, patch_180_vfs2.txt The Slide Webdav lib supports encrypted HTTPS connections. So it should be possible to add https support to vfs too. currently the webdav provider creates http urls (in WebdavClientFactory.java). maybe some provider like 'webdavs' could be added to switch to HttpsUrl. regards werner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
