[
https://issues.apache.org/jira/browse/VFS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912572#action_12912572
]
Sebb commented on VFS-317:
--------------------------
In that case, the problem is definitely that getSystemName() is returning null,
i.e. there was some problem with the SYST call which is used to determine the
system type.
What does the SYST command return?
I've updated NET trunk in SVN to give a better error if the problem occurs, so
you might like to try using the current Commons Net code.
> FTPS bug: filesystem connected, but can't operate with files due to "Could
> not determine the type of file" error.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: VFS-317
> URL: https://issues.apache.org/jira/browse/VFS-317
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: Nightly Builds
> Environment: Windows 7 x64
> jdk1.6.0_18
> commons-net-2.0.jar
> Reporter: Yurii Kartsev
> Priority: Critical
>
> Hello.
> I've build VFS from trunk(revision 993538) where user James Carman applied
> FTPS patch from issue VFS-264.
> Using the built library I've managed to successfully connect to FTPS server,
> but I can't make any file operation, including a check if file exists. I use
> this code for it:
> ---------------------------------------------------------
> FileObject dir = null;
> String fileName =
> ",AMCPROD,derivative_pricing_ssb_cds_20100910_00.xml.pgp,U,20100910A00012022189.txt";
> /*
> .... dir initialization
> */
> FileObject neededFile = dir.resolveFile(fileName);
> return neededFile.exists(); // <----- here the exception is thrown
> ---------------------------------------------------------
> Here is the stack trace(including preceding vfs DEBUG logs):
> ---------------------------------------------------------
> 09-17 15:34:25.748 EDT [main] INFO
> org.apache.commons.vfs.impl.StandardFileSystemManager - Using
> "/tmp/vfs_cache" as temporary files store.
> 09-17 15:34:26.50 EDT [main] DEBUG
> org.apache.commons.vfs.impl.StandardFileSystemManager - Skipping provider
> "org.apache.commons.vfs.provider.http.HttpFileProvider" because required
> class "org.apache.commons.httpclient.HttpClient" is not available.
> 09-17 15:34:26.51 EDT [main] DEBUG
> org.apache.commons.vfs.impl.StandardFileSystemManager - Skipping provider
> "org.apache.commons.vfs.provider.https.HttpsFileProvider" because required
> class "org.apache.commons.httpclient.HttpClient" is not available.
> 09-17 15:34:26.77 EDT [main] DEBUG
> org.apache.commons.vfs.impl.StandardFileSystemManager - Skipping provider
> "org.apache.commons.vfs.provider.sftp.SftpFileProvider" because required
> class "com.jcraft.jsch.JSch" is not available.
> 09-17 15:34:26.80 EDT [main] DEBUG
> org.apache.commons.vfs.impl.StandardFileSystemManager - Skipping provider
> "org.apache.commons.vfs.provider.webdav.WebdavFileProvider" because required
> class "org.apache.commons.httpclient.HttpClient" is not available.
> 09-17 15:34:27.871 EDT [main] DEBUG
> org.apache.commons.vfs.cache.SoftRefFilesCache - putFile:
> ftps://193.44.23.12:9001/archive
> 09-17 15:34:27.877 EDT [main] DEBUG
> org.apache.commons.vfs.cache.SoftRefFilesCache - putFile: file:///
> 09-17 15:34:27.878 EDT [main] DEBUG
> org.apache.commons.vfs.cache.SoftRefFilesCache - putFile:
> ftps://193.44.23.12:9001/archive/,AMCPROD,derivative_pricing_ssb_cds_20100910_00.xml.pgp,U,20100910A00012022189.txt
> 09-17 15:34:27.879 EDT [main] DEBUG
> org.apache.commons.vfs.cache.SoftRefFilesCache - putFile:
> ftps://193.44.23.12:9001/
> org.apache.commons.vfs.FileSystemException: Could not determine the type of
> file
> "ftps://193.44.23.12:9001/archive/,AMCPROD,derivative_pricing_ssb_cds_20100910_00.xml.pgp,U,20100910A00012022189.txt".
> at
> org.apache.commons.vfs.provider.AbstractFileObject.getType(AbstractFileObject.java:476)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.exists(AbstractFileObject.java:448)
> at
> com.ssc.otc.ftpservice.core.FtpXClient.isSourceFileExist(FtpXClient.java:179)
> at com.ssc.otc.ftpservice.core.FtpManager.copyFile(FtpManager.java:105)
> at com.ssc.otc.ftpservice.ConsoleStart.runNewTask(ConsoleStart.java:102)
> at com.ssc.otc.ftpservice.ConsoleStart.main(ConsoleStart.java:67)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
> Caused by: org.apache.commons.net.ftp.parser.ParserInitializationException:
> Parser key cannot be null
> at
> org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:82)
> at
> org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2263)
> at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2046)
> at
> org.apache.commons.vfs.provider.ftps.FtpsClientWrapper.listFiles(FtpsClientWrapper.java:116)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.doGetChildren(FtpFileObject.java:140)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getChildFile(FtpFileObject.java:110)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:198)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:321)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.getType(AbstractFileObject.java:467)
> ... 10 more
> ---------------------------------------------------------
> Please help me to solve this bug. I assume it's a bug because the connection
> is established, the file IS there, but the type can't be determined. Maybe
> FTPS patch author forgot something?
> Thanks in advance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
