You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Otto Fowler (JIRA)" <ji...@apache.org> on 2018/02/15 21:06:00 UTC
[jira] [Comment Edited] (VFS-398) FtpFileObject.getChildren() fails
when a folder contains a file with a colon in the name
[ https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366257#comment-16366257 ]
Otto Fowler edited comment on VFS-398 at 2/15/18 9:05 PM:
----------------------------------------------------------
resolveName takes a base name and the name.
The issue is that the code was written to support the base name being a full URI as opposed to bing 'just' a name.
So it supports both:
base -> foo://test/data
name ->bar
AND
base -> foo://test/data
name -> foo://test/data/bar
It therefore needs to get the scheme from the 'name' so it can decide if it needs to prepend the base or not.
The issue is that the code to extract the schema just searches for the first ':' as the schema marker.
Therefore IF you pass in a 'name' parameter that is NOT a full URI,
base -> foo://test/data
name -> b:ar
You will see this because we then try to normalize the uri, thinking it has a scheme but it doesn't.
If you have a full URI parameter, then you will probably not see this.
I ran this test in LocalProviderTestCase, FileNameTest
{code:java}
public void testColonNames() throws Exception {
final FileObject readFolder = getReadFolder();
final FileObject dirOfDeath = readFolder.resolveFile("dirOfDeath");
Assert.assertTrue("Missing dirOfDeath", dirOfDeath.exists());
final FileName noBoom = getManager().resolveName(dirOfDeath.getName(), dirOfDeath.getURL() + "/file:GoBoom");
System.out.println("Made it!");
try {
final FileName boom = getManager().resolveName(dirOfDeath.getName(), "file:GoBoom");
}catch(Exception e) {
Assert.assertTrue(false);
}
}
{code}
{code:java}
Made it!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.apache.commons.vfs2.provider.local.test.FileNameTests.testColonNames(FileNameTests.java:60)
{code}
So there is no need to mark up the names, or override. I think the correct fix is to have the parse schema function be a little smarter.
was (Author: ottobackwards):
resolveName takes a base name and the name.
The issue is that the code was written to support the base name bing a full URI as opposed to bing 'just' a name.
So it supports both:
base -> foo://test/data
name ->bar
AND
base -> foo://test/data
name -> foo://test/data/bar
It therefore needs to get the scheme from the 'name' so it can decide if it needs to prepend the base or not.
The issue is that the code to extract the schema just searches for the first ':' as the schema marker.
Therefore IF you pass in a 'name' parameter that is NOT a full URI,
base -> foo://test/data
name -> b:ar
You will see this because we then try to normalize the uri, thinking it has a scheme but it doesn't.
If you have a full URI parameter, then you will probably not see this.
I ran this test in LocalProviderTestCase, FileNameTest
{code:java}
public void testColonNames() throws Exception {
final FileObject readFolder = getReadFolder();
final FileObject dirOfDeath = readFolder.resolveFile("dirOfDeath");
Assert.assertTrue("Missing dirOfDeath", dirOfDeath.exists());
final FileName noBoom = getManager().resolveName(dirOfDeath.getName(), dirOfDeath.getURL() + "/file:GoBoom");
System.out.println("Made it!");
try {
final FileName boom = getManager().resolveName(dirOfDeath.getName(), "file:GoBoom");
}catch(Exception e) {
Assert.assertTrue(false);
}
}
{code}
{code:java}
Made it!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.apache.commons.vfs2.provider.local.test.FileNameTests.testColonNames(FileNameTests.java:60)
{code}
So there is no need to mark up the names, or override. I think the correct fix is to have the parse schema function be a little smarter.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
> ----------------------------------------------------------------------------------------
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
> Reporter: Mark Leonard
> Priority: Blocker
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme() method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision&revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using AbstractFileName.checkName()
> Sample code:
> FileObject fo = VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file");
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException: Invalid descendent file name "PREFIX:SUFFIX".
> at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)