[jira] [Commented] (VFS-210) Wrapper-Mode VFS
[ https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13999688#comment-13999688 ] Mario Ivankovits commented on VFS-210: -- Hi Bernd! Sorry for my late response. Sure, you can do whatever it requires to keep the project running! Thanks for that! Best regards, Mario > Wrapper-Mode VFS > > > Key: VFS-210 > URL: https://issues.apache.org/jira/browse/VFS-210 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: Mario Ivankovits >Assignee: Mario Ivankovits > Fix For: 2.1 > > > VFS should behave more like a wrapper to the underlaying library than a full > blown filesystem. > This should solve the following problems: > * access of hidden files/directories > * access to special folders > * speed up FTP access -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] Commented: (VFS-307) VFS issues a lot of FTP commands when listing a directory
[ https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863765#action_12863765 ] Mario Ivankovits commented on VFS-307: -- It seems there is no FTP spec which allows to escape/quote a path so that it works on each and every ftp server. So I landed at solution 2 similar to what the patch in VFS-123 proposed. It seems to work with my ftp server. > VFS issues a lot of FTP commands when listing a directory > - > > Key: VFS-307 > URL: https://issues.apache.org/jira/browse/VFS-307 > Project: Commons VFS > Issue Type: Improvement >Reporter: Mario Ivankovits > Fix For: Nightly Builds > > > Hello Mario, > > We at JetBrains are implementing support for (S)FTP sync in our IDEs using > Commons VFS. When looking at the performance, we noticed that FTP provider is > somewhat not perfect: see my discussion with Ralph. > > So the question is: why FtpClientWrapper changes the current directory to > issue 'LIST' command and restoring it back afterwards instead of issuing > single 'LIST '? > > Subversion says it was you who introduced this behavior far back in 2008. > Hope you remember those times and reason why you did this. > > Thanks a lot in advance, > > Kirill Safonov > JetBrains, Inc > http://www.jetbrains.com > "Develop with pleasure!" > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-307) VFS issues a lot of FTP commands when listing a directory
[ https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved VFS-307. -- Fix Version/s: Nightly Builds Resolution: Fixed Please give it a try > VFS issues a lot of FTP commands when listing a directory > - > > Key: VFS-307 > URL: https://issues.apache.org/jira/browse/VFS-307 > Project: Commons VFS > Issue Type: Improvement >Reporter: Mario Ivankovits > Fix For: Nightly Builds > > > Hello Mario, > > We at JetBrains are implementing support for (S)FTP sync in our IDEs using > Commons VFS. When looking at the performance, we noticed that FTP provider is > somewhat not perfect: see my discussion with Ralph. > > So the question is: why FtpClientWrapper changes the current directory to > issue 'LIST' command and restoring it back afterwards instead of issuing > single 'LIST '? > > Subversion says it was you who introduced this behavior far back in 2008. > Hope you remember those times and reason why you did this. > > Thanks a lot in advance, > > Kirill Safonov > JetBrains, Inc > http://www.jetbrains.com > "Develop with pleasure!" > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-307) VFS issues a lot of FTP commands when listing a directory
[ https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863727#action_12863727 ] Mario Ivankovits commented on VFS-307: -- The change happened when implementing the umbrella issue [1] more concret it was the issue [2] for which we did this. Hmmm ... So, I see three ways to move on: 1) leave as is, which surely is a performance penalty and not good for any DIE 2) change to try first LIST and fallback to the current way if directory is not found 3) change to LIST and try to "escape" the path in a way which makes it work with spaces in it I'll try to see if I can make 3 work and go up the list then :-) > VFS issues a lot of FTP commands when listing a directory > - > > Key: VFS-307 > URL: https://issues.apache.org/jira/browse/VFS-307 > Project: Commons VFS > Issue Type: Improvement >Reporter: Mario Ivankovits > > Hello Mario, > > We at JetBrains are implementing support for (S)FTP sync in our IDEs using > Commons VFS. When looking at the performance, we noticed that FTP provider is > somewhat not perfect: see my discussion with Ralph. > > So the question is: why FtpClientWrapper changes the current directory to > issue 'LIST' command and restoring it back afterwards instead of issuing > single 'LIST '? > > Subversion says it was you who introduced this behavior far back in 2008. > Hope you remember those times and reason why you did this. > > Thanks a lot in advance, > > Kirill Safonov > JetBrains, Inc > http://www.jetbrains.com > "Develop with pleasure!" > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VFS-307) VFS issues a lot of FTP commands when listing a directory
VFS issues a lot of FTP commands when listing a directory - Key: VFS-307 URL: https://issues.apache.org/jira/browse/VFS-307 Project: Commons VFS Issue Type: Improvement Reporter: Mario Ivankovits Hello Mario, We at JetBrains are implementing support for (S)FTP sync in our IDEs using Commons VFS. When looking at the performance, we noticed that FTP provider is somewhat not perfect: see my discussion with Ralph. So the question is: why FtpClientWrapper changes the current directory to issue 'LIST' command and restoring it back afterwards instead of issuing single 'LIST '? Subversion says it was you who introduced this behavior far back in 2008. Hope you remember those times and reason why you did this. Thanks a lot in advance, Kirill Safonov JetBrains, Inc http://www.jetbrains.com "Develop with pleasure!" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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&focusedCommentId=12675791#action_12675791 ] Mario Ivankovits commented on VFS-203: -- Hmmm normally escaping these special charachters should do the trick, e.g. %20 instead of space. It might not look nice, but this is how URIs work (IMHO) > 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 > > Windows supports file names with spaces and '#'. AFAIK spaces are not allowed > in URIs and # will be interpreted as an URI fragment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-106) VFS Truezip provider
[ https://issues.apache.org/jira/browse/VFS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661856#action_12661856 ] Mario Ivankovits commented on VFS-106: -- commons-compress is on the way of providing writable zip support (and probably others), no need to get truezip into play here. Would be great if someone could have a at integrating commons-compress trunk into a new filesystem in vfs-sandbox. > VFS Truezip provider > - > > Key: VFS-106 > URL: https://issues.apache.org/jira/browse/VFS-106 > Project: Commons VFS > Issue Type: New Feature >Reporter: Filip Defoort > Attachments: TzFileObject.java, TzFileProvider.java, > TzFileSystem.java, vfs-tz.patch > > > Attached is a quicky truezip provider to allow for read/write access to > zip/tar/... archives. > See https://truezip.dev.java.net/ for details on truezip. > Let me know how you want to proceed with something like this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-218) .skip() always returns the same number as given as parameter while the stream itself may or may not skip to given position
[
https://issues.apache.org/jira/browse/VFS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved VFS-218.
--
Resolution: Invalid
Hi!
... and so does this code snippet
{code}
FileInputStream fis = new FileInputStream("C:/temp/bla.txt");
long skipped = fis.skip(9L);
System.out.println(skipped+" <= prints 9, this should be 6 as
per javadoc's specification; "+
"http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#skip(long)");
{code}
And this is due to a bug/feature in java [1] which has already been added to
the documentation of FileInputStream [2].
Clearly, FileInputStream breaks the contract of its interface.
Seems like you are out of luck.
Ciao,
Mario
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6294974
[2] http://java.sun.com/javase/6/docs/api/java/io/FileInputStream.html
> .skip() always returns the same number as given as parameter while the stream
> itself may or may not skip to given position
> --
>
> Key: VFS-218
> URL: https://issues.apache.org/jira/browse/VFS-218
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Java 5, using jdk1.6.0_06 on Windows XP SP3
>Reporter: Not Telling
>
> The code below should reproduce the bug, so far I've tested this with file:
> and res: file systems and at least those two expose this bug. As you may
> notice from the source, you should have file called "bla.txt" containing
> "blabla" (6 characters) in your C:\temp\ folder for this.
> {code:title=VFSStreamSkipping.java}
> import java.io.IOException;
> import java.io.InputStream;
> import org.apache.commons.vfs.FileObject;
> import org.apache.commons.vfs.FileSystemException;
> import org.apache.commons.vfs.FileSystemManager;
> import org.apache.commons.vfs.VFS;
> /**
> * This class demonstrates buggy behaviour of .skip() when using VFS.
> * The bug is that no matter how many bytes were actually skipped, .skip()
> * always returns the same number as the user tried to skip. The stream itself
> * may get skipped though, if one tries to read the stream in this example
> * after .skip(), it will return -1 indicating that .skip() was executed
> * properly.
> */
> public class VFSStreamSkipping {
>
> public static void main(String[] args) {
> FileObject file;
> FileSystemManager fsm;
> try {
> fsm = VFS.getManager();
> } catch (FileSystemException e) {
> fsm = null;
> }
>
> InputStream is = null;
>
> try {
> file = fsm.resolveFile("file:C:/temp/bla.txt");
> // file content is simply "blabla" with no \n or \r
> is = file.getContent().getInputStream();
> } catch (FileSystemException e) {}
>
> try {
> long skipped = is.skip(9L);
> System.out.println(skipped+" <= prints 9, this should
> be 6 as per javadoc's specification; "+
>
> "http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#skip(long)");
>
> System.out.println(is.read());
> } catch (IOException e) {}
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599590#action_12599590 ] Mario Ivankovits commented on VFS-196: -- Just in case it is not clear, with "first" version I mean the "null" check. The symbolic check stuff should be fine. BTW. In case of isSymbolicLink, you can also use this.getLinkDestination().getName() instead of doing the name-resolve yourself. > FTP Provider Does Not Support Symbolic Links Correctly > -- > > Key: VFS-196 > URL: https://issues.apache.org/jira/browse/VFS-196 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1, 2.0 > > Attachments: symbolic_links.patch > > > If a directory is a symbolic link, it shows up as file type "imaginary" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599589#action_12599589 ] Mario Ivankovits commented on VFS-196: -- In VFS 2 we need the first version where "nul" will be returned in case of listFiles didn't return something which indicates that this was a file and not a directory and thus this file had "null" children. > FTP Provider Does Not Support Symbolic Links Correctly > -- > > Key: VFS-196 > URL: https://issues.apache.org/jira/browse/VFS-196 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1, 2.0 > > Attachments: symbolic_links.patch > > > If a directory is a symbolic link, it shows up as file type "imaginary" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-197) Maven2 Build Fails
[ https://issues.apache.org/jira/browse/VFS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599581#action_12599581 ] Mario Ivankovits commented on VFS-197: -- If you know how to fix maven to copy the test resources around I am fine if you are commit that thing then :-) Just keep in mind that the ancient ant script is not broken afterwards (just in case you move directories around) Thanks! > Maven2 Build Fails > -- > > Key: VFS-197 > URL: https://issues.apache.org/jira/browse/VFS-197 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: James Carman > Fix For: 1.1 > > Original Estimate: 1h > Remaining Estimate: 1h > > On my machine, the maven2 build fails with the following exception: > --- > Test set: org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase > --- > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec <<< > FAILURE! > testDefaultInstance(org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase) > Time elapsed: 0.018 sec <<< FAILURE! > junit.framework.AssertionFailedError: Test file > "C:\Users\jcarman\IdeaProjects\commons-vfs-clean\core\target\test-classes\test-data\test.jar" > does not exist. > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.assertTrue(Assert.java:20) > at > org.apache.commons.AbstractVfsTestCase.getTestResource(AbstractVfsTestCase.java:85) > at > org.apache.commons.AbstractVfsTestCase.getTestResource(AbstractVfsTestCase.java:71) > at > org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase.testDefaultInstance(FileSystemManagerFactoryTestCase.java:45) > at > org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase.testDefaultInstance(FileSystemManagerFactoryTestCase.java:45) > 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:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > 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:585) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > 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:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) > The problem is that the maven build isn't copying the test data over into the > target folder. I can fix this, but it will mean moving the test data around > a bit by putting it in the src/main/resources (the standard place for testing > resources for m2). I'll attach a patch illustrating my changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599580#action_12599580 ] Mario Ivankovits commented on VFS-196: -- Go on an commit it please! Thanks! > FTP Provider Does Not Support Symbolic Links Correctly > -- > > Key: VFS-196 > URL: https://issues.apache.org/jira/browse/VFS-196 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1 > > Attachments: symbolic_links.patch > > > If a directory is a symbolic link, it shows up as file type "imaginary" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-210) Wrapper-Mode VFS
[
https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599578#action_12599578
]
Mario Ivankovits commented on VFS-210:
--
Yes!
I haven't changed the API so far and I do not plan to do so. There are just a
few changes in the contract VFS had with some of it's abstract methods in
AbstractFileObject. Nothing too serious so far.
If your code does something like this ...
FileObject fo = VFS.getManager().resolveFile("ftp://xyz/";);
if (fo.getType().hasChildren())
{
// traverse fo
fo.getChildren();
}
... you should not see any changes. But you could also not expect any
performance increase as you called getType().
With the commits today you will be able to:
FileObject fo = VFS.getManager().resolveFile("ftp://xyz/";);
// traverse fo
fo.getChildren();
This will no longer call getType(), not in your code nor within VFS. Thus, it
is no longer required to list the parent directory which was a real pain.
You will get a FileNotFolderException from getChildren() if the file wasn't a
directory instead.
Both modes work in parallel. It just depends on the way how you use the VFS API.
> Wrapper-Mode VFS
>
>
> Key: VFS-210
> URL: https://issues.apache.org/jira/browse/VFS-210
> Project: Commons VFS
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Mario Ivankovits
>Assignee: Mario Ivankovits
> Fix For: 2.0
>
>
> VFS should behave more like a wrapper to the underlaying library than a full
> blown filesystem.
> This should solve the following problems:
> * access of hidden files/directories
> * access to special folders
> * speed up FTP access
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (VFS-210) Wrapper-Mode VFS
Wrapper-Mode VFS Key: VFS-210 URL: https://issues.apache.org/jira/browse/VFS-210 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 2.0 VFS should behave more like a wrapper to the underlaying library than a full blown filesystem. This should solve the following problems: * access of hidden files/directories * access to special folders * speed up FTP access -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-195) Unable to get Zip file URL working on Windows machine
[ https://issues.apache.org/jira/browse/VFS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563417#action_12563417 ] Mario Ivankovits commented on VFS-195: -- It depends as you can also write zip:///home/im/Downloads/10387.zip!/ which works perfectly too. so you can leave out the "//" only if you nest other filesystems like in "zip:file". Yes, documentation can be better, but I am really poor in doing so (or too lazy ;-) ) so any contribution in this area is very welcome. Ciao, Mario > Unable to get Zip file URL working on Windows machine > - > > Key: VFS-195 > URL: https://issues.apache.org/jira/browse/VFS-195 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Rajiv Kumar > > Could not get the Zip file URL working on Windows machine? Tried following > formats. > zip:file:/C:/Temp/source/test.zip --- Invalid Absolute URI > zip:file:/C:/Temp/source/test.zip! --- Invalid Absolute URI > zip:file://C:/Temp/source/test.zip --- Invalid Absolute URI > zip:file:/C:/Temp/source/test.zip! -- Invalid Absolute URI > zip://file:/C:/Temp/source/test.zip -- > org.apache.commons.vfs.FileSystemException: Could not copy because it does > not exist. > zip:///C:/Temp/source/test.zip! - Could not copy because it does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-195) Unable to get Zip file URL working on Windows machine
[
https://issues.apache.org/jira/browse/VFS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563404#action_12563404
]
Mario Ivankovits commented on VFS-195:
--
Hi!
If this is your code then it is very clear for me that it will not work ;-)
Look at fsm.addProvider("zip") where you add the localProvider again insted of
the zipProvider.
Ciao,
Mario
> Unable to get Zip file URL working on Windows machine
> -
>
> Key: VFS-195
> URL: https://issues.apache.org/jira/browse/VFS-195
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Rajiv Kumar
>
> Could not get the Zip file URL working on Windows machine? Tried following
> formats.
> zip:file:/C:/Temp/source/test.zip --- Invalid Absolute URI
> zip:file:/C:/Temp/source/test.zip! --- Invalid Absolute URI
> zip:file://C:/Temp/source/test.zip --- Invalid Absolute URI
> zip:file:/C:/Temp/source/test.zip! -- Invalid Absolute URI
> zip://file:/C:/Temp/source/test.zip --
> org.apache.commons.vfs.FileSystemException: Could not copy because it does
> not exist.
> zip:///C:/Temp/source/test.zip! - Could not copy because it does not exist.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (VFS-195) Unable to get Zip file URL working on Windows machine
[ https://issues.apache.org/jira/browse/VFS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits closed VFS-195. Resolution: Invalid Please join us on the user mailinglist to solve this topic! Thanks! Ciao, Mario > Unable to get Zip file URL working on Windows machine > - > > Key: VFS-195 > URL: https://issues.apache.org/jira/browse/VFS-195 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Rajiv Kumar > > Could not get the Zip file URL working on Windows machine? Tried following > formats. > zip:file:/C:/Temp/source/test.zip --- Invalid Absolute URI > zip:file:/C:/Temp/source/test.zip! --- Invalid Absolute URI > zip:file://C:/Temp/source/test.zip --- Invalid Absolute URI > zip:file:/C:/Temp/source/test.zip! -- Invalid Absolute URI > zip://file:/C:/Temp/source/test.zip -- > org.apache.commons.vfs.FileSystemException: Could not copy because it does > not exist. > zip:///C:/Temp/source/test.zip! - Could not copy because it does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-195) Unable to get Zip file URL working on Windows machine
[
https://issues.apache.org/jira/browse/VFS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563142#action_12563142
]
Mario Ivankovits commented on VFS-195:
--
Hmmm I think the examples on our web-page [1] are rather self-explaining,
aren't they?
I had no chance to test this on a windows machine yet, but my try on linux with
the latest VFS snapshot the following worked:
FileObject fo =
VFS.getManager().resolveFile("zip:file:///home/im/Downloads/commons-compress-draft.zip");
or
FileObject fo =
VFS.getManager().resolveFile("zip:file:///home/im/Downloads/commons-compress-draft.zip!/");
If you do not use VFS.getManager() you have to ensure you setup VFS correctly
e.g. by adding all wanted providers.
As always, please try the latest nightly build too.
BTW: Please do not use JIRA as disuccsion platform. I am going to close this
bug again and looking forward that we help you on the user list until we all
conclude that this is a bug.
Ciao,
Mario
[1] http://commons.apache.org/vfs/filesystems.html#Zip__Jar_and_Tar
> Unable to get Zip file URL working on Windows machine
> -
>
> Key: VFS-195
> URL: https://issues.apache.org/jira/browse/VFS-195
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Rajiv Kumar
>
> Could not get the Zip file URL working on Windows machine? Tried following
> formats.
> zip:file:/C:/Temp/source/test.zip --- Invalid Absolute URI
> zip:file:/C:/Temp/source/test.zip! --- Invalid Absolute URI
> zip:file://C:/Temp/source/test.zip --- Invalid Absolute URI
> zip:file:/C:/Temp/source/test.zip! -- Invalid Absolute URI
> zip://file:/C:/Temp/source/test.zip --
> org.apache.commons.vfs.FileSystemException: Could not copy because it does
> not exist.
> zip:///C:/Temp/source/test.zip! - Could not copy because it does not exist.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-194) Redirect of HTTP url using the header location
[
https://issues.apache.org/jira/browse/VFS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561011#action_12561011
]
Mario Ivankovits commented on VFS-194:
--
could you attach a "svn diff" with the whole patch please.
Thanks!
Mario
> Redirect of HTTP url using the header location
> --
>
> Key: VFS-194
> URL: https://issues.apache.org/jira/browse/VFS-194
> Project: Commons VFS
> Issue Type: Wish
> Environment: Windows XP/Linux/FreeBSD
>Reporter: Yves Zoundi
>
> The http provider classes don't test the header location before resolving a
> file. If the redirection is reported as invalid by commons-httpclient, then
> the HttpFileObject is not resolved. Here is how to fix it in all the http
> provider implementation classes.
> int status = 0;//client.executeMethod(method);
> try{
> status = client.executeMethod(method);
> System.out.println("method executed");
> }
> catch(Exception e){
> System.out.println("Exception co");
> try{
> HostConfiguration config =
> client.getHostConfiguration();
> Header header =
> method.getResponseHeader("Location");
> System.out.println("Checking header");
> if (header != null) {
>
> String redirectUrl = header.getValue();
> config.setHost(new
> java.net.URL(redirectUrl).getHost(), config.getPort(), config.getProtocol());
> client.setHostConfiguration(config);
> status = client.executeMethod(method);
>
> }
> }
> catch(Exception err){
> throw new Exception(err);
> }
>
> }
>if ((status >= 300) && (status < 400)) {
> try{
> HostConfiguration config =
> client.getHostConfiguration();
> Header header =
> method.getResponseHeader("Location");
> if (header != null) {
>
> String redirectUrl = header.getValue();
> method = new HeadMethod();
>setupMethod(method);
> config.setHost(new
> java.net.URL(redirectUrl).getHost(), config.getPort(), config.getProtocol());
> client.setHostConfiguration(config);
> status = client.executeMethod(method);
>
> }
> }
> catch(Exception err){
> throw new Exception(err);
> }
>}
> method.releaseConnection();
> if (status == HttpURLConnection.HTTP_OK)
> {
> return FileType.FILE;
> }
> else if (status == HttpURLConnection.HTTP_NOT_FOUND
> || status == HttpURLConnection.HTTP_GONE)
> {
> return FileType.IMAGINARY;
> }
> else
> {
> throw new FileSystemException("vfs.provider.http/head.error",
> getName());
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-178) Indicate that passive FTP (and other options) should be used when writing to a FTP location
[ https://issues.apache.org/jira/browse/VFS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537229 ] Mario Ivankovits commented on VFS-178: -- Sorry for being so busy lately with other things This patch is just for vfs.passive and just for ftp, but we need a more general solution for this by using the DelegatingFileSystemOptionsBuilder.setConfigString() method. Done right it will immediately allow to set any configuration exposed through the various FileSystemOptionBuilders ... and any future addition too - as long as it is possible to create the required value-type out of a simple string. > Indicate that passive FTP (and other options) should be used when writing to > a FTP location > --- > > Key: VFS-178 > URL: https://issues.apache.org/jira/browse/VFS-178 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: Nightly Builds >Reporter: Asankha C. Perera > Attachments: vfs-ftp.patch > > > I am trying to use VFS to connect to a FTP file, but the problem is that I > cannot specify that PASSIVE mode should be used. I think we could use the > format below to specify for example: ?passive=true etc. > ftp://myusername:[EMAIL PROTECTED]/pub/downloads/somefile.tgz?option=value > Referece thread > http://mail-archives.apache.org/mod_mbox/commons-dev/200709.mbox/[EMAIL > PROTECTED] > > I think the use of the ?? would not be a good URI scheme. However, maybe we > > > could simply make the VFS parameters unique. For example add vfs. in front > > > of them. > > > > > > For example, > > > http://www/path/cgi-bin/send.pl?FILE=ABC&TYPE=PDF&vfs.proxyHost=proxy.host&vfs.proxyPort=8080 > > > > Yes, for sure, this could make it too - I thought about it too. Even if > I am still not that happy with this query-string parsing/repacking stuff > I'd commit it if someone contributes a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-120) SFTP-Exception: "com.jcraft.jsch.JSchException: session is down" if the SFTP-Server was killed and restarted (a normal shutdown of the SFTP-Server occured no Exception after
[ https://issues.apache.org/jira/browse/VFS-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved VFS-120. -- Resolution: Fixed Fix Version/s: 1.1 Assignee: Mario Ivankovits I think I found a fix without relying on the exception text. There is a session.isConnected() which seems to work fine. Please give it a try. Thanks! > SFTP-Exception: "com.jcraft.jsch.JSchException: session is down" if the > SFTP-Server was killed and restarted (a normal shutdown of the SFTP-Server > occured no Exception after restart.) > --- > > Key: VFS-120 > URL: https://issues.apache.org/jira/browse/VFS-120 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.0 > Environment: Tomcat 5.5 > JDK 6.0 (build with JDK 5) > commons-vfs-1.0.jar: > Specification-Title: Commons VFS > Implementation-Version: 1.0 > JSCH: jsch-0.1.31.jar >Reporter: Harald Brabenetz >Assignee: Mario Ivankovits >Priority: Critical > Fix For: 1.1 > > Attachments: SftpFileSystem-patch.txt > > > The error occured after restarting if the SFTP-Server was KILLed!!. > With a normal shutdown of the SFTP-Server, no exception after restarting > occured. > I found no function to force the reset of the session in SftpFileSystem.java > There is a function: > DefaultFileSystemManager manager = > (DefaultFileSystemManager)VFS.getManager(); > manager.freeUnusedResources(); > But this works only if AbstractFileSystem.isReleaseable() returns true. > And this this function return only true if all SFTP-FileObject are removed > from the GarbageCollection (finally()-Methode). > I cannot force a GarbageCollection. > So there is no way to handle this Error! I must restart the VM > (ServletContainer). > org.apache.commons.vfs.FileSystemException: Could not copy > "file:///C:/TEMP/." to "sftp://..";. > at > org.apache.commons.vfs.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:902) > at > com.bearingpoint.orf.chat.core.service.ExportManagerImpl.exportChatMessages(Unknown > Source) > at > com.bearingpoint.orf.chat.core.service.ExportManagerImpl.startExportNow(Unknown > Source) > at > com.bearingpoint.orf.chat.core.service.ExportManagerImpl$ExportManagerRunnable.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:595) > Caused by: org.apache.commons.vfs.FileSystemException: Could not write to > "sftp://chat:[EMAIL PROTECTED]/home/chat/chatfile_12.zip". > at > org.apache.commons.vfs.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1227) > at > org.apache.commons.vfs.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:373) > at > org.apache.commons.vfs.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:356) > at org.apache.commons.vfs.FileUtil.copyContent(FileUtil.java:100) > at > org.apache.commons.vfs.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:893) > ... 4 more > Caused by: org.apache.commons.vfs.FileSystemException: Could not connect to > SFTP server at "sftp://chat:[EMAIL PROTECTED]/". > at > org.apache.commons.vfs.provider.sftp.SftpFileSystem.getChannel(SftpFileSystem.java:144) > at > org.apache.commons.vfs.provider.sftp.SftpFileObject.doGetOutputStream(SftpFileObject.java:402) > at > org.apache.commons.vfs.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1219) > ... 8 more > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Session.openChannel(Session.java:756) > at > org.apache.commons.vfs.provider.sftp.SftpFileSystem.getChannel(SftpFileSystem.java:122) > ... 10 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-172) Cache of SFTP after move completely out of sync.
[
https://issues.apache.org/jira/browse/VFS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved VFS-172.
--
Resolution: Fixed
Fix Version/s: 1.1
Assignee: Mario Ivankovits
Applied - Thanks for the patch!
Also implemented the refresh() method now to make the CachePolicy work with
sftp too.
Test case still works, so it looks good to me.
> Cache of SFTP after move completely out of sync.
>
>
> Key: VFS-172
> URL: https://issues.apache.org/jira/browse/VFS-172
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Joerg Schaible
>Assignee: Mario Ivankovits
>Priority: Critical
> Fix For: 1.1
>
> Attachments: VFS-172.diff
>
>
> Simple test method. See all the bogus cases at the end:
> {code:java}
> public void testObjectsAfterMoveOfParentDoNotExistWithSFTP() throws
> IOException
> {
> final FileSystemOptions fsOptions = new FileSystemOptions();
> final FileSystemManager fsManager = VFS.getManager();
> final FileObject root = fsManager.resolveFile(SFTP_BASE_URL +
> "junit", fsOptions);
> if (!root.exists()) {
> root.createFolder();
> }
> assertTrue(root.exists());
> final FileObject target = root.resolveFile("target");
> if (!target.exists()) {
> target.createFolder();
> }
> assertTrue(target.exists());
> final FileObject work = root.resolveFile("work");
> if (!work.exists()) {
> work.createFolder();
> }
> assertTrue(work.exists());
> FileObject inWork = work.resolveFile("inWork");
> if (!inWork.exists()) {
> inWork.createFolder();
> }
> assertTrue(inWork.exists());
> final FileObject ready = target.resolveFile("ready-" +
> System.currentTimeMillis());
> assertFalse(ready.exists());
> work.moveTo(ready);
> assertTrue(ready.exists());
> assertFalse(work.exists());
> try {
> assertFalse(inWork.exists());
> fail("Thrown " + AssertionFailedError.class.getName() +
> " expected, because of buggy implementation");
> } catch (final AssertionFailedError e) {
> //
> }
> try {
> inWork.refresh();
> assertFalse(inWork.exists());
> fail("Thrown " + AssertionFailedError.class.getName() +
> " expected, because of buggy implementation");
> } catch (final AssertionFailedError e) {
> //
> }
> try {
> assertFalse(work.resolveFile("inWork").exists());
> fail("Thrown " + AssertionFailedError.class.getName() +
> " expected, because of buggy implementation");
> } catch (final AssertionFailedError e) {
> //
> }
> try {
> work.refresh();
> assertFalse(work.resolveFile("inWork").exists());
> fail("Thrown " + AssertionFailedError.class.getName() +
> " expected, because of buggy implementation");
> } catch (final AssertionFailedError e) {
> //
> }
>
> // it even possible to write into a file of the non-existing
> folder ...
> FileObject file = inWork.resolveFile("test.txt");
> OutputStream out = file.getContent().getOutputStream();
> out.write("Foo".getBytes());
> try {
> out.close();
> } catch(IOException e) {
> // ignore this
> }
> assertTrue(file.exists());
> // force update of references
> file = null;
> out = null;
> inWork = null;
> System.gc();
> System.gc();
> // ... a ... something changed
> assertFalse(work.resolveFile("inWork").exists());
> }
> {code}
> There's not a single possibility to tell VFS that the FileObject is bogus and
> even worse, you can write into non-existing files of a non-existing folder
> without getting an Exception ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
