[jira] [Updated] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-15 Thread Shon Vella (JIRA) 

 [ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shon Vella updated VFS-620:
---
Attachment: VFS-620c.patch

Sorry - I guess that what I get for trying to copy and paste the changes into 
the existing patch instead of doing a new diff from the sources that are 
working for me. Updated patch uploaded.



> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620c.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-15 Thread Shon Vella (JIRA) 

 [ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shon Vella updated VFS-620:
---
Attachment: (was: VFS-620.patch)

> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-14 Thread Shon Vella (JIRA) 

[ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924521#comment-15924521
 ] 

Shon Vella edited comment on VFS-620 at 3/14/17 4:36 PM:
-

Updated patch.
Sorry about that. My original version of the added tests were failing without 
the update to the provider, but then before I submitted, I refactored the tests 
to minimize the changes and forgot to retest the original failure with the new 
tests and it turns out that I missed a few things in the refactored tests that 
were causing it to run the tests without the userDirIsRoot flag set.


was (Author: svella):
Updated patch

> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-14 Thread Shon Vella (JIRA) 

 [ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shon Vella updated VFS-620:
---
Attachment: (was: VFS-620.patch)

> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-14 Thread Shon Vella (JIRA) 

 [ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shon Vella updated VFS-620:
---
Attachment: VFS-620.patch

Updated patch

> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-07 Thread Shon Vella (JIRA) 

[ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15900317#comment-15900317
 ] 

Shon Vella edited comment on VFS-620 at 3/7/17 10:35 PM:
-

This appears to be a duplicate of both VFS-188 and VFS-292, both of which had 
patches submitted last decade without so much as an acknowledgment, though 
neither patch is exactly right, in that they don't account for the possibility 
of a decorator on the source FileObject no include an updated test case. Here 
is a new patch VFS-620.patch that accounts for that and adds in a test case 
that causes the entire suite being run against the FTP provider to be run both 
with and without the UserDirIsRoot option.


was (Author: svella):
This appears to be a duplicate of both VFS-188 and VFS-292, both of which had 
patches submitted last decade without so much as an acknowledgment, though 
neither patch is exactly right, in that they don't account for the possibility 
of a decorator on the source FileObject no include an updated test case. Here 
is a new patch that accounts for that and adds in a test case that causes the 
entire suite being run against the FTP provider to be run both with and without 
the UserDirIsRoot option.

> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-07 Thread Shon Vella (JIRA) 

 [ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shon Vella updated VFS-620:
---
Attachment: VFS-620.patch

This appears to be a duplicate of both VFS-188 and VFS-292, both of which had 
patches submitted last decade without so much as an acknowledgment, though 
neither patch is exactly right, in that they don't account for the possibility 
of a decorator on the source FileObject no include an updated test case. Here 
is a new patch that accounts for that and adds in a test case that causes the 
entire suite being run against the FTP provider to be run both with and without 
the UserDirIsRoot option.

> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-03 Thread Shon Vella (JIRA) 

[ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15895200#comment-15895200
 ] 

Shon Vella commented on VFS-620:


I just ran into this with UserDirIsRoot=true. When stepping through it, it 
looks to me like the problem is in FtpFileObject.doRename():
{code}
final String oldName = getName().getPath();
final String newName = newFile.getName().getPath();
{code}
should be:
{code}
final String oldName = relPath;
final String newName = 
((FtpFileObject)FileObjectUtils.getAbstractFileObject(newFile)).getRelPath();
{code}

I'll submit a patch if I have time before someone actually gets to this.

> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (VFS-515) AbstractFileObject.getURL() returns flaky URL object

2014-03-05 Thread Shon Vella (JIRA) 
Shon Vella created VFS-515:
--

 Summary: 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.2#6252)

[jira] [Created] (VFS-481) Default moveTo does not work for non-empty directories when it can't be done via renaming.

2013-07-31 Thread Shon Vella (JIRA) 
Shon Vella created VFS-481:
--

 Summary: Default moveTo does not work for non-empty directories 
when it can't be done via renaming.
 Key: VFS-481
 URL: https://issues.apache.org/jira/browse/VFS-481
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Shon Vella


The default implementation of moveTo in AbstractFileObject has no chance of 
working for a non-empty folder in cases where it can't be done via a rename. 
This is because it calls it calls copyFrom with Selectors.SELECT_SELF which 
will not copy the descendants and doDelete, which is documented as only 
supposed to be called when This file has no children, if a folder.

--
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] [Commented] (VFS-481) Default moveTo does not work for non-empty directories when it can't be done via renaming.

2013-07-31 Thread Shon Vella (JIRA) 

[ 
https://issues.apache.org/jira/browse/VFS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13725596#comment-13725596
 ] 

Shon Vella commented on VFS-481:


This didn't work in 1.x either, but it was even worse there because it did a 
recursive delete after the non-recursive copy, thus deleting originals that 
were not copied.

 Default moveTo does not work for non-empty directories when it can't be done 
 via renaming.
 --

 Key: VFS-481
 URL: https://issues.apache.org/jira/browse/VFS-481
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Shon Vella

 The default implementation of moveTo in AbstractFileObject has no chance of 
 working for a non-empty folder in cases where it can't be done via a rename. 
 This is because it calls it calls copyFrom with Selectors.SELECT_SELF which 
 will not copy the descendants and doDelete, which is documented as only 
 supposed to be called when This file has no children, if a folder.

--
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