[jira] [Commented] (LANG-1002) Several predefined ISO FastDateFormats in DateFormatUtils are incorrect
[
https://issues.apache.org/jira/browse/LANG-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906136#comment-14906136
]
Michael Osipov commented on LANG-1002:
--
Yes, they are.
> Several predefined ISO FastDateFormats in DateFormatUtils are incorrect
> ---
>
> Key: LANG-1002
> URL: https://issues.apache.org/jira/browse/LANG-1002
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.3.2
>Reporter: Michael Osipov
>Assignee: Charles Honton
> Fix For: 3.5
>
>
> Formats {{ISO_TIME_FORMAT}}, {{ISO_TIME_TIME_ZONE_FORMAT}} prepend a {{T}}
> but this is not correct. Sole time is never prepended by defintion. {{T}} is
> used only when date *and* time are given.
> The Javadocs of {{ISO_TIME_NO_T_FORMAT}}, {{ISO_TIME_NO_T_FORMAT}} are in
> correct too because they say: "This pattern does not comply with the formal
> ISO8601 specification as the standard requires the 'T' prefix for times."
> You might want to read [Markus Kuhn's
> reference|https://www.cl.cam.ac.uk/~mgk25/iso-time.html#time] on that.
> A solution would be remove the first two and rename the second two by
> dropping the {{NO_T}} in the name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VFS-567) Timeout in vsFTPd causes exception when executing another command
[ https://issues.apache.org/jira/browse/VFS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906040#comment-14906040 ] Antonio Petrelli commented on VFS-567: -- Thanks Bernd, however, as I am an emeritus PMC member of other Apache project, I remember that the name of the contributor should be inserted in the commit log. > Timeout in vsFTPd causes exception when executing another command > - > > Key: VFS-567 > URL: https://issues.apache.org/jira/browse/VFS-567 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 > Environment: vsFTPd 3.0.2 on Kubuntu 14.10 >Reporter: Antonio Petrelli >Assignee: Bernd Eckenfels > Fix For: 2.1 > > Attachments: commons-vfs-disconnect.diff, vfs-quit-problem.zip > > > After a timeout in vsFTPd, a QUIT command is sent and a 421 Timeout response > is sent back to the Java client. After that, a SocketException (broken pipe) > is raised and not correctly managed. > I am attaching a test case, this is the stack trace: > Exception in thread "main" org.apache.commons.vfs2.FileSystemException: Could > not determine the type of file "ftps://localhost/javadev/vfs/input". > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:1526) > at QuitProblemMain.main(QuitProblemMain.java:41) > Caused by: java.net.SocketException: Pipe interrotta > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) > at java.net.SocketOutputStream.write(SocketOutputStream.java:153) > at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431) > at sun.security.ssl.OutputRecord.write(OutputRecord.java:417) > at > sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:864) > at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:835) > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) > at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) > at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) > at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) > at java.io.BufferedWriter.flush(BufferedWriter.java:254) > at org.apache.commons.net.ftp.FTP.__send(FTP.java:505) > at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:479) > at > org.apache.commons.net.ftp.FTPSClient.sendCommand(FTPSClient.java:541) > at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:608) > at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:582) > at org.apache.commons.net.ftp.FTP.quit(FTP.java:864) > at > org.apache.commons.vfs2.provider.ftp.FTPClientWrapper.disconnect(FTPClientWrapper.java:118) > at > org.apache.commons.vfs2.provider.ftp.FTPClientWrapper.listFiles(FTPClientWrapper.java:152) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetChildren(FtpFileObject.java:136) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildFile(FtpFileObject.java:106) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:192) > at > org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:320) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:1517) > ... 1 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VFS-580) Improve FTP error messages
L created VFS-580:
-
Summary: Improve FTP error messages
Key: VFS-580
URL: https://issues.apache.org/jira/browse/VFS-580
Project: Commons VFS
Issue Type: Improvement
Affects Versions: Nightly Builds, 2.1
Reporter: L
FTP provider classes throw FileSystemException is some operations cannot be
performed. It would be really nice if the exceptions also included
ftpClient.getReplyString() in the message.
Reason: normally an error is reported to a user by using getMessage() on the
exception instance. The errors reported by FTP provider look now too generic
and cannot help diagnose the issue.
For example, FtpFileObject.doCreateFolder() has this code:
if (!ok)
{
throw new
FileSystemException("vfs.provider.ftp/create-folder.error", getName());
}
The reported error looks like:
Could not create FTP directory dir_name.
Why the operation failed? Only the stack trace can help.
There are of course more places where adding ftpClient.getReplyString() makes
sense.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (POOL-304) GenericKeyedObjectPool doesn't have getKeys() implemented
[ https://issues.apache.org/jira/browse/POOL-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed POOL-304. Resolution: Fixed Obsolete pre-release pool2 web site removed in r966614. > GenericKeyedObjectPool doesn't have getKeys() implemented > - > > Key: POOL-304 > URL: https://issues.apache.org/jira/browse/POOL-304 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Dexter Legaspi > > getKeys() not really implemented as specified here: > https://commons.apache.org/proper/commons-pool2/apidocs/org/apache/commons/pool2/impl/GenericKeyedObjectPool.html#getKeys() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VFS-581) FTPClientWrapper hides important error information
L created VFS-581: - Summary: FTPClientWrapper hides important error information Key: VFS-581 URL: https://issues.apache.org/jira/browse/VFS-581 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds, 2.1 Reporter: L One place where FTPClientWrapper hides errors is method listFilesInDirectory(). 1. Lines 163-167: After performing getFtpClient().listFiles(relPath); the code checks for a positive FTP reply. 2. If the reply was negative, the code assumes the negative reply has to do with VFS-307 as stated in the comments. This is not always the case, there might be other reasons why the operation might have failed. In my case it was an FTPS connection where the server required an encrypted data channel and the client did was not properly configured. 3. Line 182: getFtpClient().listFiles();. This time without even looking at the FTP reply string. In my case it was the same error as above. As a result my client got an empty as if the remote directory did not have any files, while the real error reason was nowhere to see. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (VFS-524) The uri include ipv6 address can't be parsed out correctly
[
https://issues.apache.org/jira/browse/VFS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Legner updated VFS-524:
-
Attachment: VFS-524-v3.patch
v3 also includes the brackets in {{name.getURI()}}.
> The uri include ipv6 address can't be parsed out correctly
> --
>
> Key: VFS-524
> URL: https://issues.apache.org/jira/browse/VFS-524
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Alex
> Fix For: 2.1
>
> Attachments: VFS-524-v2.patch, VFS-524-v3.patch
>
>
> I am using apache commons vfs2 to read and download file in ipv6 enviroment,
> but it seems can't parse out ipv6 address correctly
> The URI is just like:
> ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test
> The error message:
> Invalid absolute URI "ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test;.
> Caused by : Expecting / to follow the hostname in URI
> "ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test;.
> Deep into the code, I found the root cause is that HostFileNameParser's
> extractHostName can't parse out the host name correctly
> {noformat}
> /**
> * Extracts the hostname from a URI. The scheme://userinfo@ part has
> * been removed.
> */
> protected String extractHostName(final StringBuilder name)
> {
> final int maxlen = name.length();
> int pos = 0;
> for (; pos < maxlen; pos++)
> {
> final char ch = name.charAt(pos);
> if (ch == '/' || ch == ';' || ch == '?' || ch == ':'
> || ch == '@' || ch == '&' || ch == '=' || ch == '+'
> || ch == '$' || ch == ',')
> {
> break;
> }
> }
> if (pos == 0)
> {
> return null;
> }
> final String hostname = name.substring(0, pos);
> name.delete(0, pos);
> return hostname;
> }
> {noformat}
> From the code, we are able to know it will parse out the host name by colon,
> but for ipv6, it will get a wrong host name
> There is the same problem with the other protocol like sftp and cifs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (VFS-582) incompatible naming change for tests
Bernd Eckenfels created VFS-582: --- Summary: incompatible naming change for tests Key: VFS-582 URL: https://issues.apache.org/jira/browse/VFS-582 Project: Commons VFS Issue Type: Bug Affects Versions: 2.1 Reporter: Bernd Eckenfels Assignee: Bernd Eckenfels Priority: Minor Fix For: 2.1 While verifying 2.1-SNAPSHOT with my own VFS provider I noticed that it breaks the test build because getTestDirectoryFile was renamed to getTestDirectory. This was a cleanup outside of the released API, but there is no reason to try to stay compatible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-515) AbstractFileObject.getURL() returns flaky URL object
[
https://issues.apache.org/jira/browse/VFS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906900#comment-14906900
]
Simon Legner commented on VFS-515:
--
I don't understand why everything except the schema (i.e.,
{{//localhost/etc/hosts}}) is put in the {{file}} part
({{org/apache/commons/vfs2/provider/AbstractFileObject.java:1550}}) …
> AbstractFileObject.getURL() returns flaky URL object
>
>
> Key: VFS-515
> URL: https://issues.apache.org/jira/browse/VFS-515
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
> Environment: OSX 10.9.2
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
>Reporter: Shon Vella
>
> URL returned is created with constructor that expects host as a separate
> parameter from path and passes in empty string for host. As a result
> subsequent calls to url.getHost() returns an empty string rather than the
> host encoded in the path.
> Test Code
> FileSystemManager fsManager = VFS.getManager();
> FileObject f = fsManager.resolveFile("ftp://localhost/etc/hosts;);
> URL url = f.getURL();
> String host = url.getHost();
> assertEquals("localhost", host);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VFS-203) FileObject..getName().getURI() returns URIs with spaces
[
https://issues.apache.org/jira/browse/VFS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907101#comment-14907101
]
Joerg Schaible commented on VFS-203:
Not true for Unix:
{noformat}
$ touch \?\"\\\*.txt
$ ls -1 *.txt
?"\*.txt
$ rm *.txt
{noformat}
> FileObject..getName().getURI() returns URIs with spaces
> ---
>
> Key: VFS-203
> URL: https://issues.apache.org/jira/browse/VFS-203
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Tim Lebedkov
> Attachments: VFD-203-v2.patch, VFD-203-v3.patch, patch.txt
>
>
> Windows supports file names with spaces and '#'. AFAIK spaces are not allowed
> in URIs and # will be interpreted as an URI fragment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (VFS-203) FileObject..getName().getURI() returns URIs with spaces
[ https://issues.apache.org/jira/browse/VFS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Legner updated VFS-203: - Attachment: VFD-203-v3.patch Moved the test to GenericFileNameTestCase. The comment "? is a reserved filesystem character for Windows and Unix, so can't be part of a filename" still has to be clarified … > FileObject..getName().getURI() returns URIs with spaces > --- > > Key: VFS-203 > URL: https://issues.apache.org/jira/browse/VFS-203 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Tim Lebedkov > Attachments: VFD-203-v2.patch, VFD-203-v3.patch, patch.txt > > > Windows supports file names with spaces and '#'. AFAIK spaces are not allowed > in URIs and # will be interpreted as an URI fragment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (VFS-179) Traversal of directory tree with FileSelector fails with symbolic links in SFTP
[
https://issues.apache.org/jira/browse/VFS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Legner updated VFS-179:
-
Attachment: VFS-179-v2.patch
Here is an updated patch against trunk (r1705120).
> Traversal of directory tree with FileSelector fails with symbolic links in
> SFTP
> ---
>
> Key: VFS-179
> URL: https://issues.apache.org/jira/browse/VFS-179
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Andrew Franklin
> Attachments: VFS-179-v2.patch, VFS-179.patch
>
>
> It seems to me that when using the FileSelector to traverse a directory tree
> using SFTP, a symbolic link will return as type File (even when the link
> points to a directory), which will result in the directory node not being
> followed.
> By using a mechanism similar to that of FtpFileObject this can be resolved
> with the following...
> {noformat}
> protected FileType doGetType() throws Exception
> {
> if (attrs == null)
> {
> statSelf();
> }
> if (attrs == null)
> {
> return FileType.IMAGINARY;
> }
> if ((attrs.getFlags() & SftpATTRS.SSH_FILEXFER_ATTR_PERMISSIONS) == 0)
> {
> throw new FileSystemException(
> "vfs.provider.sftp/unknown-permissions.error");
> }
> if(attrs.isLink())
> {
> return getLinkDestination().getType();
> }
> else if (attrs.isDir())
> {
> return FileType.FOLDER;
> }
> else
> {
> return FileType.FILE;
> }
> }
> /**
> * Return the destination of this file object if it's a symbolic link
> * @return FileObject representing the linked to location
> */
> private FileObject getLinkDestination() throws Exception
> {
> if (linkDestination == null)
> {
> final String path = fileSystem.getChannel().readlink( relPath );
> FileName relativeTo = getName().getParent();
> if (relativeTo == null)
> {
> relativeTo = getName();
> }
> FileName linkDestinationName =
> getFileSystem().getFileSystemManager().resolveName(relativeTo, path);
> linkDestination =
> getFileSystem().resolveFile(linkDestinationName);
> }
> return linkDestination;
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (VFS-492) Support FEAT and MLSx commands for FTP performance improvements.
[
https://issues.apache.org/jira/browse/VFS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Legner updated VFS-492:
-
Attachment: VFS-492-v2.patch
The provided patch looks very decent. I applied the patch against trunk,
resolved minor issues (maven dependency couldn't be resolved,
{{DefaultProtocolTestCase}} failed since {{server.setServerControlPort(0)}} was
missing) and reformatted to stick to the code style conventions.
> Support FEAT and MLSx commands for FTP performance improvements.
>
>
> Key: VFS-492
> URL: https://issues.apache.org/jira/browse/VFS-492
> Project: Commons VFS
> Issue Type: Improvement
>Affects Versions: 2.0
> Environment: Development:
> Windows 7 Pro.
> Java 1.7.0_25
> Eclipse SDK 4.2.2
> Target:
> All
>Reporter: Scott Embler
>Priority: Minor
> Labels: noob, patch, performance
> Attachments: VFS-492-v2.patch, ftp-mlsx.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> While using VFS to synchronize/push files between a local file system and an
> FTP server I noticed severe performance issues whenever the FTP directory had
> a large number of files. Each refresh of an FtpFileObject asks for a list of
> the files in the parent directory, and then attempts to pick out the
> information for a single file. Performance will degrade quickly as the
> number of files to be listed increases.
> I'd suggest using MLST and MLSD as an alternative to LIST, where possible.
> MLST can retrieve the necessary file information without listing a whole
> directory. Both commands also provide unambiguous time-stamps, which was
> also a problem that I ran into while trying to compare modification times
> between the local and FTP file systems.
> Attached is a patch that probably does the job. In cases where MLSx features
> are not supported, the original LIST command will be used. Tests are
> included. Since I'm new to VFS I'm not sure if this covers all cases, so be
> warned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (VFS-203) FileObject..getName().getURI() returns URIs with spaces
[
https://issues.apache.org/jira/browse/VFS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907101#comment-14907101
]
Joerg Schaible edited comment on VFS-203 at 9/24/15 9:57 PM:
-
Not true for Unix:
{noformat}
$ touch \?\"\\\*.txt
$ ls -1 *.txt
?"\*.txt
$ rm *.txt
{noformat}
Actually it depends also on the underlying file system. You can use NT in Linux
or Ext3 in Windows. Wonder, what VFS can do about ...
was (Author: joehni):
Not true for Unix:
{noformat}
$ touch \?\"\\\*.txt
$ ls -1 *.txt
?"\*.txt
$ rm *.txt
{noformat}
> FileObject..getName().getURI() returns URIs with spaces
> ---
>
> Key: VFS-203
> URL: https://issues.apache.org/jira/browse/VFS-203
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Tim Lebedkov
> Attachments: VFD-203-v2.patch, VFD-203-v3.patch, patch.txt
>
>
> Windows supports file names with spaces and '#'. AFAIK spaces are not allowed
> in URIs and # will be interpreted as an URI fragment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VFS-566) No file returned when using findFiles on a directory in HTTP
[
https://issues.apache.org/jira/browse/VFS-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907105#comment-14907105
]
Simon Legner commented on VFS-566:
--
In my understanding, this is addressed by VFS-199 and its patch.
> No file returned when using findFiles on a directory in HTTP
>
>
> Key: VFS-566
> URL: https://issues.apache.org/jira/browse/VFS-566
> Project: Commons VFS
> Issue Type: Wish
>Affects Versions: 2.0
>Reporter: Giuseppe Lio
>Priority: Minor
>
> I am trying to list the content of a folder with HTTP doing something like:
> FileObject remoteFolderObj = fsManager.resolveFile("http://lio:18080/test/;);
> FileObject[] files = remoteFolderObj.findFiles(allFileSelector);
> where allFileSelector is a FileSelector which returns all the file.
> Doing this findFiles method returns no file even if there are files in the
> folder.
> When I go to:
> http://lio:18080/test/
> using a browser I can see the list of the files in the folder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DBCP-448) Disable password exposure via JMX.
Michał Jedynak created DBCP-448: --- Summary: Disable password exposure via JMX. Key: DBCP-448 URL: https://issues.apache.org/jira/browse/DBCP-448 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 2.1 Reporter: Michał Jedynak Priority: Minor Currently there is no control over which methods are exposed as mbeans via JMX in BasicDataSource. The main issue with this approach is that 'getPassword' method is also exposed which is most of the time problematic on production environments. It would be nice to have some control over the exposed methods to be able to disable password exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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=14906967#comment-14906967
]
Simon Legner commented on VFS-398:
--
[~markjleonard], thank you for the clarification.
Consider a file {{/foo:bar:baz/foo:bar}} relative to FTP root and calling
{{VFS.getManager().resolveFile("ftp://localhost:2121/foo:bar:baz;).getChildren()}}.
In
{{org.apache.commons.vfs2.impl.DefaultFileSystemManager#resolveName(org.apache.commons.vfs2.FileName,
java.lang.String, org.apache.commons.vfs2.NameScope)}} from the method
parameter {{name}} (which is considered relative to the root) a scheme is
extracted. This yields {{foo}} as scheme and subsequent test {{(scheme == null
&& buffer.charAt(0) != FileName.SEPARATOR_CHAR)}} is negative.
The scheme extraction for the relative {{name}} has been integrated in revision
780730. I wonder why.
> 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=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
(v6.3.4#6332)
[jira] [Commented] (VFS-203) FileObject..getName().getURI() returns URIs with spaces
[ https://issues.apache.org/jira/browse/VFS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907222#comment-14907222 ] Sebb commented on VFS-203: -- Unix paths can contain anything apart from NUL. Path segments can obviously not contain '/' so filenames cannot contain '/' or NUL. However some characters are treated specially by the Unix shell(s), and have to be escaped. This does not mean that they cannot be used in file names. E.g. ? * ( ) ; space NL [and quite a few others] > FileObject..getName().getURI() returns URIs with spaces > --- > > Key: VFS-203 > URL: https://issues.apache.org/jira/browse/VFS-203 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Tim Lebedkov > Attachments: VFD-203-v2.patch, VFD-203-v3.patch, patch.txt > > > Windows supports file names with spaces and '#'. AFAIK spaces are not allowed > in URIs and # will be interpreted as an URI fragment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (VFS-582) incompatible naming change for tests
[ https://issues.apache.org/jira/browse/VFS-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved VFS-582. - Resolution: Fixed Fixed with this commit: http://svn.apache.org/viewvc?rev=1705120=rev > incompatible naming change for tests > > > Key: VFS-582 > URL: https://issues.apache.org/jira/browse/VFS-582 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Minor > Labels: test-compile > Fix For: 2.1 > > > While verifying 2.1-SNAPSHOT with my own VFS provider I noticed that it > breaks the test build because getTestDirectoryFile was renamed to > getTestDirectory. This was a cleanup outside of the released API, but there > is no reason to try to stay compatible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-376) SFTP uri is throwing error when .. is using in path
[
https://issues.apache.org/jira/browse/VFS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907027#comment-14907027
]
Simon Legner commented on VFS-376:
--
Traversing upwards is not necessary when one uses
{{org.apache.commons.vfs2.provider.sftp.SftpFileSystemConfigBuilder#setUserDirIsRoot}}
beforehand. I would close this issue as INVALID.
> SFTP uri is throwing error when .. is using in path
> ---
>
> Key: VFS-376
> URL: https://issues.apache.org/jira/browse/VFS-376
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Ajesh babu
>Priority: Minor
> Labels: patch
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Hi
> We are using apache commons vfs2 for sftp file upload & download , but in one
> scenario it is always giving an error like
> "SEVERE: FileSystemException ->org.apache.commons.vfs2.FileSystemException:
> Invalid absolute URI "
> The uri is like
> "sftp://sftpuser:{AFF12398KYUJN982FGTB}@172.24.0.114:22/../../../../app/utenti/sftpuser/output/transaction_CARTASI_20200429083817.csv;
> The user home directory of sftpuser is 'app/utenti/sftpuser' , we want to use
> another directory which is not under app/utenti/sftpuser, so we tried to
> traverse the parent directory using ../../ but UriParser:normalisePath()
> method is always giving error ,
> in the below code portion
> // A '..' element - remove the previous element
> if (startElem == startFirstElem)
> {
> // Previous element is missing
> throw new FileSystemException(
> "vfs.provider/invalid-relative-path.error");
> }
> But in jdk URI it is saying that
> public URI normalize()
> Normalizes this URI's path.
> If this URI is opaque, or if its path is already in normal form, then
> this URI is returned. Otherwise a new URI is constructed that is identical to
> this URI except that its path is computed by normalizing this URI's path in a
> manner consistent with RFC 2396, section 5.2, step 6, sub-steps c through f;
> that is:
>1.
> All "." segments are removed.
>2.
> If a ".." segment is preceded by a non-".." segment then both of
> these segments are removed. This step is repeated until it is no longer
> applicable.
>3.
> If the path is relative, and if its first segment contains a colon
> character (':'), then a "." segment is prepended. This prevents a relative
> URI with a path such as "a:b/c/d" from later being re-parsed as an opaque URI
> with a scheme of "a" and a scheme-specific part of "b/c/d". (Deviation from
> RFC 2396)
> A normalized path will begin with one or more ".." segments if there were
> insufficient non-".." segments preceding them to allow their removal. A
> normalized path will begin with a "." segment if one was inserted by step 3
> above. Otherwise, a normalized path will not contain any "." or ".." segments.
> Returns:
> A URI equivalent to this URI, but whose path is in normal form
> So can you please tell us how can we use ../../ in a uri for traversing to
> the parent directory.
> If we are passing the path like
> sftp://sftpuser:{AFF12398KYUJN982FGTB}@172.24.0.114:22/output/transaction_CARTASI_20200429083817.csv
> this it is working fine, in this case 'output' directory is under sftpuser's
> home directory (app/utenti/sftpuser}
> Please treat it as urgent and pls help us
> Thanks in advance
> Ajesh Babu
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
