[jira] [Updated] (COMPRESS-676) OSGi: MANIFEST.MF contains unsolvable imports
[
https://issues.apache.org/jira/browse/COMPRESS-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated COMPRESS-676:
-
Priority: Minor (was: Major)
> OSGi: MANIFEST.MF contains unsolvable imports
> -
>
> Key: COMPRESS-676
> URL: https://issues.apache.org/jira/browse/COMPRESS-676
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.26.0, 1.26.1
>Reporter: Martin Schneider
>Assignee: Bernd Eckenfels
>Priority: Minor
> Fix For: 1.27.0
>
>
> In an OSGi environment im- and exports of bundles are based on java package
> declarations.
> The MANIFEST.MF file shipped with the commons compress bundle contains two
> imports of packages that cannot be solved:
> {{org.apache.commons.commons-codec}} and {{org.apache.commons.commons-io.}}
> As there are already imports to packages of these bundles
> ({{{}org.apache.commons.codec,org.apache.commons.codec.digest,org.apache.commons.io,org.apache.commons.io.build,org.apache.commons.io.file.attribute,org.apache.commons.io.input,org.apache.commons.io.output)
> {}}}the two wrong imports can probably simply be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COMPRESS-676) OSGi: MANIFEST.MF contains unsolvable imports
[
https://issues.apache.org/jira/browse/COMPRESS-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated COMPRESS-676:
-
Labels: osgi (was: )
> OSGi: MANIFEST.MF contains unsolvable imports
> -
>
> Key: COMPRESS-676
> URL: https://issues.apache.org/jira/browse/COMPRESS-676
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.26.0, 1.26.1
>Reporter: Martin Schneider
>Assignee: Bernd Eckenfels
>Priority: Minor
> Labels: osgi
> Fix For: 1.27.0
>
>
> In an OSGi environment im- and exports of bundles are based on java package
> declarations.
> The MANIFEST.MF file shipped with the commons compress bundle contains two
> imports of packages that cannot be solved:
> {{org.apache.commons.commons-codec}} and {{org.apache.commons.commons-io.}}
> As there are already imports to packages of these bundles
> ({{{}org.apache.commons.codec,org.apache.commons.codec.digest,org.apache.commons.io,org.apache.commons.io.build,org.apache.commons.io.file.attribute,org.apache.commons.io.input,org.apache.commons.io.output)
> {}}}the two wrong imports can probably simply be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (COMPRESS-676) OSGi: MANIFEST.MF contains unsolvable imports
[
https://issues.apache.org/jira/browse/COMPRESS-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels resolved COMPRESS-676.
--
Fix Version/s: 1.27.0
Assignee: Bernd Eckenfels
Resolution: Fixed
I removed the uneeded commons-codec and turned the wrong commons-io into
correct optional (incl. subpackages). The optional OSGI dependencies test did
not test for it to be optional, so I added it. It looks like some usecases
might work without. Thanks for reporting.
> OSGi: MANIFEST.MF contains unsolvable imports
> -
>
> Key: COMPRESS-676
> URL: https://issues.apache.org/jira/browse/COMPRESS-676
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.26.0, 1.26.1
>Reporter: Martin Schneider
>Assignee: Bernd Eckenfels
>Priority: Major
> Fix For: 1.27.0
>
>
> In an OSGi environment im- and exports of bundles are based on java package
> declarations.
> The MANIFEST.MF file shipped with the commons compress bundle contains two
> imports of packages that cannot be solved:
> {{org.apache.commons.commons-codec}} and {{org.apache.commons.commons-io.}}
> As there are already imports to packages of these bundles
> ({{{}org.apache.commons.codec,org.apache.commons.codec.digest,org.apache.commons.io,org.apache.commons.io.build,org.apache.commons.io.file.attribute,org.apache.commons.io.input,org.apache.commons.io.output)
> {}}}the two wrong imports can probably simply be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (BEANUTILS-549) Update commons-lang dependency to commons-lang3
[ https://issues.apache.org/jira/browse/BEANUTILS-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved BEANUTILS-549. --- Fix Version/s: 2.0.0 (was: 1.9.4) Resolution: Fixed > Update commons-lang dependency to commons-lang3 > --- > > Key: BEANUTILS-549 > URL: https://issues.apache.org/jira/browse/BEANUTILS-549 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.9.3 >Reporter: Steve Lopez >Priority: Minor > Fix For: 2.0.0 > > > current version relies on quite outdated commons-lang. request is to update > to use commons-lang3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (BEANUTILS-475) beanutils could use commons-collections4 instead of commons-collections 3
[ https://issues.apache.org/jira/browse/BEANUTILS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved BEANUTILS-475. --- Resolution: Fixed > beanutils could use commons-collections4 instead of commons-collections 3 > - > > Key: BEANUTILS-475 > URL: https://issues.apache.org/jira/browse/BEANUTILS-475 > Project: Commons BeanUtils > Issue Type: Bug >Reporter: Thibault Kruse >Priority: Minor > Fix For: 2.0.0 > > > just curious. > collections4 seems to be out since 2013, maybe could be advertized more > inside apache -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-322) Allow minus for kebab-case options
[
https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated CLI-322:
Description:
Currently minus (“-“) is not allowed in option names,
which makes common long options in kebab-case
(like {{--is-not-allowed}}) impossible.
This change is to allow it inside an option name.
was:Currently minus (`-`) is not allowed in option names, which makes common
long options in kebab-case (like`-\-is-not-allowed`) impossible. This change is
to allow it inside an option name.
> Allow minus for kebab-case options
> --
>
> Key: CLI-322
> URL: https://issues.apache.org/jira/browse/CLI-322
> Project: Commons CLI
> Issue Type: New Feature
> Components: Parser
>Affects Versions: 1.6.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: 1.7.0
>
>
> Currently minus (“-“) is not allowed in option names,
> which makes common long options in kebab-case
> (like {{--is-not-allowed}}) impossible.
> This change is to allow it inside an option name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CLI-322) Allow minus for kebab-case options
[ https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated CLI-322: Description: Currently minus (`-`) is not allowed in option names, which makes common long options in kebab-case (like`-\-is-not-allowed`) impossible. This change is to allow it inside an option name. (was: Currently the '-' is not allowed in the option name. This change is to allow '-' as an option name.) Summary: Allow minus for kebab-case options (was: Allow kabab-case options) > Allow minus for kebab-case options > -- > > Key: CLI-322 > URL: https://issues.apache.org/jira/browse/CLI-322 > Project: Commons CLI > Issue Type: New Feature > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > Currently minus (`-`) is not allowed in option names, which makes common long > options in kebab-case (like`-\-is-not-allowed`) impossible. This change is to > allow it inside an option name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1720) Add better description of possible exception thrown by methods in the Javadoc
[ https://issues.apache.org/jira/browse/LANG-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790582#comment-17790582 ] Bernd Eckenfels commented on LANG-1720: --- If the API relies on communicating call errors with runtime exceptions its very useful to document them, especially if you describe the condition they happen. for a low level lib it can be argued thats good for performance reaqsons, for other APIs i would say its a failure inchecking preconditions - however not something which can be changed risk-free. So adding the @throws is my preference as well. > Add better description of possible exception thrown by methods in the Javadoc > - > > Key: LANG-1720 > URL: https://issues.apache.org/jira/browse/LANG-1720 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Sheung Chi Chan >Priority: Trivial > > Some static methods in the Conversion class do document that > IndexOutOfBoundsException or NullPointerException will be thrown from the > method in some cases. But there are some methods missing those documentation > in the Javadoc comments which could result in unexpected exceptions thrown. > It is suggested to have better description of what known exception could be > thrown from the methods. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1720) Add better description of possible exception thrown by methods in the Javadoc
[ https://issues.apache.org/jira/browse/LANG-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790263#comment-17790263 ] Bernd Eckenfels commented on LANG-1720: --- Good point, can you tell us which ones you missed the doc? > Add better description of possible exception thrown by methods in the Javadoc > - > > Key: LANG-1720 > URL: https://issues.apache.org/jira/browse/LANG-1720 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Sheung Chi Chan >Priority: Trivial > > Some static methods in the Conversion class do document that > IndexOutOfBoundsException or NullPointerException will be thrown from the > method in some cases. But there are some methods missing those documentation > in the Javadoc comments which could result in unexpected exceptions thrown. > It is suggested to have better description of what known exception could be > thrown from the methods. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747440#comment-17747440
]
Bernd Eckenfels edited comment on VFS-840 at 7/26/23 10:21 AM:
---
You could try getName().toString() or variations thereof, basically anything
which avoids getURI().
was (Author: b.eckenfels):
You could try getName().toString() or variations thereof, basically anything
which avoids getUIR().
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747440#comment-17747440
]
Bernd Eckenfels commented on VFS-840:
-
You could try getName().toString() or variations thereof, basically anything
which avoids getUIR().
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747216#comment-17747216
]
Bernd Eckenfels commented on VFS-840:
-
I would suggest to discuss usage questions on the commons-user mailing list.
The rules are annoying but simple:
- filenames have to be url encoded in most API (exception like getChild)
- fsm.resolveFile needs a fully qualified name or a base name or a base url
In you example I would try "/D:" as an absolute filename (I am not completely
sure bout the semantics, as I normally just use the before mentioned convenient
method to convert java.io.File into FileObject).
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747070#comment-17747070
]
Bernd Eckenfels commented on VFS-840:
-
The resolve always needs a base of you don’t set a base url. For example you
can use `cwd = fsm.toFileObject(new File(".")); jpg = fsm.resovleFile(cwd,
"test%5B1%5D.jpg");`
Btw also beware, fo.getChildre(fn) on the other hand does not work with url
encoding.
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747053#comment-17747053
]
Bernd Eckenfels commented on VFS-840:
-
In VFS2 you must url encode the resolveFile(argument).
Not sure if the error can maybe be thrown in another way.
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (EXEC-105) Small mistakes in the documentation for Apache Commons Exec 1.3
[ https://issues.apache.org/jira/browse/EXEC-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved EXEC-105. -- Fix Version/s: 1.4 Assignee: Gary D. Gregory Resolution: Fixed Remaining issues have been fixed (the other examples have not been reviewed) > Small mistakes in the documentation for Apache Commons Exec 1.3 > --- > > Key: EXEC-105 > URL: https://issues.apache.org/jira/browse/EXEC-105 > Project: Commons Exec > Issue Type: Wish >Affects Versions: 1.3 >Reporter: Ivan Puntev >Assignee: Gary D. Gregory >Priority: Trivial > Fix For: 1.4 > > > I want to apologize if this issue is not correctly formatted, but I am new > into the issue reporting. > On this page on the bottom - > [http://commons.apache.org/proper/commons-exec/tutorial.html] > I found wrong code example in "Unblock Your Execution paragraph". > > The "cmdLine" variable later in code changes its name to "commandLine". > At the end, this code line -> int exitValue = resultHandler.waitFor(); is > wrong because the waitFor() method is void and doesn't return any value. > > In the examples above may also have mistakes but I haven't checked. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (EXEC-105) Small mistakes in the documentation for Apache Commons Exec 1.3
[ https://issues.apache.org/jira/browse/EXEC-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743483#comment-17743483 ] Bernd Eckenfels commented on EXEC-105: -- The waitFor() problem still exists.. maybe you want to create a pull request? > Small mistakes in the documentation for Apache Commons Exec 1.3 > --- > > Key: EXEC-105 > URL: https://issues.apache.org/jira/browse/EXEC-105 > Project: Commons Exec > Issue Type: Wish >Affects Versions: 1.3 >Reporter: Ivan Puntev >Priority: Trivial > > I want to apologize if this issue is not correctly formatted, but I am new > into the issue reporting. > On this page on the bottom - > [http://commons.apache.org/proper/commons-exec/tutorial.html] > I found wrong code example in "Unblock Your Execution paragraph". > > The "cmdLine" variable later in code changes its name to "commandLine". > At the end, this code line -> int exitValue = resultHandler.waitFor(); is > wrong because the waitFor() method is void and doesn't return any value. > > In the examples above may also have mistakes but I haven't checked. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IMAGING-354) Improve vulnerability reporting
[
https://issues.apache.org/jira/browse/IMAGING-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels closed IMAGING-354.
---
Resolution: Invalid
Sorry that you had such a bad communication regarding a security issue. However
the brackermis Notwehr right way to contact the PMC or the security team.
I would discuss this on the developer list, maybe with cc to the PMC-private
list as well as the ASF security team.
Btw I cant comment on the actual issue, I am missing the background.
> Improve vulnerability reporting
> ---
>
> Key: IMAGING-354
> URL: https://issues.apache.org/jira/browse/IMAGING-354
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Marcono1234
>Priority: Major
>
> Hello,
> on May 1st I wrote to secur...@commons.apache.org and got the response:
> {quote}
> That team will be in contact with you directly once they have completed their
> investigation or if they have further questions for you. Note that as we
> often receive a lot of incoming reports, issues are generally dealt with in
> severity order so please be patient.
> {quote}
> Because I hadn't received any response so far, but there was activity in the
> commons-imaging repository, I then responded to that mail on June 4th. So far
> I still haven't received any response per mail. I think / hope I was
> reasonably patient so far, but it would have been nice to have some
> communication, for example confirming the issue, asking if a fix would solve
> the issue, respectively discussing the fix...
> Maybe there was an issue with e-mail communication, but because I received
> the initial confirmation that my mail was received, I assumed there was no
> issue with e-mail communication.
> I am not planning to disclose the issue, neither here nor somewhere else any
> time soon, and I am not asking for an immediate fix. It would just be nice to
> have communication, see also my previous mail.
> As mentioned in my mail, maybe [GitHub private vulnerability
> reporting|https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository]
> would be good additional way to support vulnerability reporting, which would
> also be more transparent than using mails.
> CC [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-835) Severe Performance Issue - FileObject.copyFrom()
[ https://issues.apache.org/jira/browse/VFS-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712099#comment-17712099 ] Bernd Eckenfels commented on VFS-835: - That sounds like a good and likely point, it can be problems with file length padding/recognition, eof character or even block alignment. That would all correlate with encryption layers. (And is all easier to find than overall resource consumption or network bandwith problems) To get to the bottom of this we need a bit more details. What is the server what kind of encryption, are all files affected or only with a certain size (multiple of 2^n-7 or such. I also wonder if it is related to VFS (especially loop logic, buffer size and file metadata) or if it’s a general problem of the ssh lib. Can you maybe check a Mina demo client? or, Can you are a test account accessible? > Severe Performance Issue - FileObject.copyFrom() > > > Key: VFS-835 > URL: https://issues.apache.org/jira/browse/VFS-835 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.6.0 >Reporter: Mahesh >Priority: Blocker > Fix For: 2.6.0 > > > We are facing severe performance with the FileObject.copyFrom() method, this > method is taking 28 minutes for 20 MB file, its faster for un encrypted files > (less than a minute), but with encryption on it is taking 28 minutes for 20 > MB. We don't have any way to trace further, can you help? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VFS-835) Severe Performance Issue - FileObject.copyFrom()
[ https://issues.apache.org/jira/browse/VFS-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709745#comment-17709745 ] Bernd Eckenfels commented on VFS-835: - Do native sftp clients have roughly the same speed, then I don’t think it is related to VFS. The sftp library is certainly not the best optimized, but that kind of performance sounds like a deeper rooted issue. When you say encryption, what kind of sftp server and file encryption is that? The only thing the sftp client can influence here might be the blocksize of the copy operation, but even that should normally not affect it this hard. Maybe try to start with test code which only reads your source or only Writer your destination, to see which one is the issue. > Severe Performance Issue - FileObject.copyFrom() > > > Key: VFS-835 > URL: https://issues.apache.org/jira/browse/VFS-835 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.6.0 >Reporter: Mahesh >Priority: Blocker > Fix For: 2.6.0 > > > We are facing severe performance with the FileObject.copyFrom() method, this > method is taking 28 minutes for 20 MB file, its faster for un encrypted files > (less than a minute), but with encryption on it is taking 28 minutes for 20 > MB. We don't have any way to trace further, can you help? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VFS-833) org.apache.commons.vfs2.FileSystemOptions#options is not synchronized
[ https://issues.apache.org/jira/browse/VFS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703793#comment-17703793 ] Bernd Eckenfels commented on VFS-833: - Thanks for the report. Can you give an example when this actually happens - I.e. who changes why fs options. This does not really work very well since they are part of the Idendity of a filesystem instance. So I would say most of the time they have to be immutable. At least this is what VFS assumes why it does not synchronize. Maybe it’s enough if we do a defensive copy? > org.apache.commons.vfs2.FileSystemOptions#options is not synchronized > - > > Key: VFS-833 > URL: https://issues.apache.org/jira/browse/VFS-833 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.9.0 >Reporter: Kannan Ramamoorthy >Priority: Major > > *Problem:* > The map `org.apache.commons.vfs2.FileSystemOptions#options` is TreeMap. The > datastructure is not thread-safe and resulting in situations like > [this|https://ivoanjo.me/blog/2018/07/21/writing-to-a-java-treemap-concurrently-can-lead-to-an-infinite-loop-during-reads/] > when used in multithreaded environments. > *Workaround:* > As a workaround, we have to synchronize the `FileSystemOptions` in all the > places of the code. > *Solution:* > * If there is no issue, the constructor ` > protected FileSystemOptions(Map options)` can be > made public, so that users will have an option to pass a synchronized map > when they have to. * Or, wrap the `TreeMap` instance with > `java.util.Collections#synchronizedMap`, ensuring thread safety at the core. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VFS-831) No such file or directory
[
https://issues.apache.org/jira/browse/VFS-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680845#comment-17680845
]
Bernd Eckenfels commented on VFS-831:
-
I am somewhat confused, how is a FileNotFound error related to maven
dependencies?
> No such file or directory
> -
>
> Key: VFS-831
> URL: https://issues.apache.org/jira/browse/VFS-831
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: OpenJDK 14 FreeBSD 13.1-RELEASE
>Reporter: Hasan Diwan
>Priority: Blocker
> Attachments: id_ecdsa.pub
>
>
> % ls -l /var/tmp/reminders.json.xz
> -rw-r--r-- 1 ec2-user wheel 32 Jan 25 19:28 /var/tmp/reminders.json.xz
> % hostname
> FileContent content =
> manager.resolveFile("/var/tmp/reminders.json.xz").getContent();
> throws an "org.apache.commons.vfs2.FileNotFoundException: Could not read from
> "file:///var/tmp/reminders.json.xz" because it is not a file."
> When I try accessing it with "sftp", it gives:
> org.apache.commons.vfs2.FileSystemException: Could not find file with URI
> "sftp://ec2-u...@hasan.d8u.us//var/tmp/reminders.json.xz; because it is a
> relative path, and no base URI was provided.
> It gives the same if I eliminate the double slash in the URL as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-827) CIFS support in Commons VFS
[ https://issues.apache.org/jira/browse/VFS-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634996#comment-17634996 ] Bernd Eckenfels commented on VFS-827: - I don’t think it is planned to be released in proper, since it depends on a external non-Apache license (LGPL) library which is meanwhile also obsoleted (SMB3 support would require jcifs-ng), Btw there are a few external providers, at least one or two for jCIFS-ng, maybe we should ask authors to donate them? (It won’t change the license situation) > CIFS support in Commons VFS > --- > > Key: VFS-827 > URL: https://issues.apache.org/jira/browse/VFS-827 > Project: Commons VFS > Issue Type: Improvement >Reporter: Sreedhar J >Priority: Major > > I see CIFS file system support is in sandbox state, Any idea, when is > CIFS support would be released? > Also, does CIFS file system has support for SMB 2.0, 2.1 and SMB 3.0 ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DBCP-587) DBCP and Transparent Application Continuity
[
https://issues.apache.org/jira/browse/DBCP-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619105#comment-17619105
]
Bernd Eckenfels commented on DBCP-587:
--
I don’t think you need the basic datasource at all:ä
OracleDataSourceImpl ds = new oracle.jdbc.replay.OracleDataSourceImpl();
ds.setUrl("jdbc:oracle:thin:@pdb_tac");
ds.setUsername("hr");
ds.setPassword("my_password");
ConnectionFactory connectionFactory = new DataSourceConnectionFactory(ds);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
> DBCP and Transparent Application Continuity
> ---
>
> Key: DBCP-587
> URL: https://issues.apache.org/jira/browse/DBCP-587
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Kirk Hill
>Priority: Major
>
> Oracle databases have a high-availability setup that uses an item called
> Transparent Application Continuity. It requires using the following driver
> class name for "oracle.jdbc.replay.OracleDataSourceImpl" When I attempt to
> use this driver I get the following error message.
> SQLException occurred : Cannot create JDBC driver of class
> 'oracle.jdbc.replay.OracleDataSourceImpl'
> Having this as a way to create connection pools would greatly enhance your
> product.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DBCP-587) DBCP and Transparent Application Continuity
[ https://issues.apache.org/jira/browse/DBCP-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617943#comment-17617943 ] Bernd Eckenfels commented on DBCP-587: -- You need to use https://commons.apache.org/proper/commons-dbcp/apidocs/org/apache/commons/dbcp2/DataSourceConnectionFactory.html instead of DriverManagerConnectionFactory to specify an instantiated DataSource subclass. > DBCP and Transparent Application Continuity > --- > > Key: DBCP-587 > URL: https://issues.apache.org/jira/browse/DBCP-587 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.9.0 >Reporter: Kirk Hill >Priority: Major > > Oracle databases have a high-availability setup that uses an item called > Transparent Application Continuity. It requires using the following driver > class name for "oracle.jdbc.replay.OracleDataSourceImpl" When I attempt to > use this driver I get the following error message. > SQLException occurred : Cannot create JDBC driver of class > 'oracle.jdbc.replay.OracleDataSourceImpl' > Having this as a way to create connection pools would greatly enhance your > product. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-310) Purge release version 20040117.000000 from Maven Central
[
https://issues.apache.org/jira/browse/CLI-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17540179#comment-17540179
]
Bernd Eckenfels commented on CLI-310:
-
> Would removing the version from the maven-metadata help here?
Yes, removing the meta data (if permanent) would help.
Its probably not the right place to discuss this, but that would be a good
improvement to the maven repo if a artifact(group) contact (like the Common
PMC) could maintain a filter list for versions not automatically
indexeded/recreated in the meta data. So the repo is still immutable in terms
of downloading older versions, but maven wont auto suggest such harmful/junk
versions.
(Another option would be if maven resolver has such a centrally maintained deny
list) - where would be a good place to discuss this? Maven-users?
> Purge release version 20040117.00 from Maven Central
>
>
> Key: CLI-310
> URL: https://issues.apache.org/jira/browse/CLI-310
> Project: Commons CLI
> Issue Type: Task
>Reporter: Markus Spann
>Priority: Minor
>
> How did commons-cli "release version" 20040117.00 make it into Maven
> Central?
> It's been there for as long as I can remember.
> It would not bother any of us if this version did not always show up as the
> most recent/latest/bleeding edge release. Even though it's ancient and noone
> would want to use it of course.
> This effect is due to this version not following the commons-cli version
> scheme and due to the way Maven sorts version strings.
> A small use case to illustrate:
>
> {code:java}
> mvn versions:display-dependency-updates
> {code}
>
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO] commons-cli:commons-cli ... 1.4 -> 20040117.00
> {code}
> I understand that purging release artifacts from Central may not be simple.
> Yet it would be so much appreciated if someone with the corresponding
> know-how and access could take care of it. Thanks a million!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (VFS-819) VFSClassLoader ClassNotFoundException JDK 17
[
https://issues.apache.org/jira/browse/VFS-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533069#comment-17533069
]
Bernd Eckenfels edited comment on VFS-819 at 5/6/22 8:01 PM:
-
In a similar situation I got this problem due to the April Java update which
introduced a JAR file mime type. You can remove it in your types.properties if
it helps. In case this is the reason for your Problem a better handling of
known file types is already in master, see my comment here:
https://github.com/apache/commons-vfs/commit/f3b7a06f28aab2db829806e0e857c05b71a14305#comments
Alternatively you might be able to register the JARFileSystem with the new
mimetype, that should also work.
was (Author: b.eckenfels):
In a similar situation I got this problem due to the April Java update which
introduced a JAR file mime type. You can remove it in your types.properties if
it helps. In case this is the reason for your Problem a better handling of
known file types is already in master, see my comment here:
https://github.com/apache/commons-vfs/commit/f3b7a06f28aab2db829806e0e857c05b71a14305#comments
> VFSClassLoader ClassNotFoundException JDK 17
>
>
> Key: VFS-819
> URL: https://issues.apache.org/jira/browse/VFS-819
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: OpenJDK 17 version "17.0.3" 2022-04-19
> Apache Maven 3.8.5
> Multiple Linux
>Reporter: Mike Miller
>Priority: Major
>
> We (Accumulo) are seeing the VFSClassLoader failing in JDK 17. We have very
> simple tests, that are all failing when trying to use it to load classes from
> the classpath.
> {noformat}
> [INFO] Running
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
> [ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 26.367 s <<< FAILURE! - in
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
> [ERROR]
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest.testGetClass
> Time elapsed: 0.02 s <<< ERROR!
> java.lang.ClassNotFoundException: test.HelloWorld
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> at
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest.testGetClass(VfsClassLoaderTest.java:66)
> {noformat}
> Here is an example:
> {code:java}
> this.cl = new VFSClassLoader(dirContents, vfs);
> @Test
> public void testGetClass() throws Exception {
> Class helloWorldClass = this.cl.loadClass("test.HelloWorld");
> Object o = helloWorldClass.getDeclaredConstructor().newInstance();
> assertEquals("Hello World!", o.toString());
> }{code}
> https://github.com/apache/accumulo/blob/main/start/src/test/java/org/apache/accumulo/start/classloader/vfs/providers/VfsClassLoaderTest.java
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (VFS-819) VFSClassLoader ClassNotFoundException JDK 17
[
https://issues.apache.org/jira/browse/VFS-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533069#comment-17533069
]
Bernd Eckenfels commented on VFS-819:
-
In a similar situation I got this problem due to the April Java update which
introduced a JAR file mime type. You can remove it in your types.properties if
it helps. In case this is the reason for your Problem a better handling of
known file types is already in master, see my comment here:
https://github.com/apache/commons-vfs/commit/f3b7a06f28aab2db829806e0e857c05b71a14305#comments
> VFSClassLoader ClassNotFoundException JDK 17
>
>
> Key: VFS-819
> URL: https://issues.apache.org/jira/browse/VFS-819
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: OpenJDK 17 version "17.0.3" 2022-04-19
> Apache Maven 3.8.5
> Multiple Linux
>Reporter: Mike Miller
>Priority: Major
>
> We (Accumulo) are seeing the VFSClassLoader failing in JDK 17. We have very
> simple tests, that are all failing when trying to use it to load classes from
> the classpath.
> {noformat}
> [INFO] Running
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
> [ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 26.367 s <<< FAILURE! - in
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
> [ERROR]
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest.testGetClass
> Time elapsed: 0.02 s <<< ERROR!
> java.lang.ClassNotFoundException: test.HelloWorld
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> at
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest.testGetClass(VfsClassLoaderTest.java:66)
> {noformat}
> Here is an example:
> {code:java}
> this.cl = new VFSClassLoader(dirContents, vfs);
> @Test
> public void testGetClass() throws Exception {
> Class helloWorldClass = this.cl.loadClass("test.HelloWorld");
> Object o = helloWorldClass.getDeclaredConstructor().newInstance();
> assertEquals("Hello World!", o.toString());
> }{code}
> https://github.com/apache/accumulo/blob/main/start/src/test/java/org/apache/accumulo/start/classloader/vfs/providers/VfsClassLoaderTest.java
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (VFS-770) FileSystemManager.createFileSystem(FileObject) fails on Gzip files.
[
https://issues.apache.org/jira/browse/VFS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527834#comment-17527834
]
Bernd Eckenfels commented on VFS-770:
-
BTW just FYI April 22 Update of Java 17 (and others) introduced new Mime types
including the ones for `.gz` (`application/gzip`) and `.jar`
(`application/java-archive`).
This bugfix helps with these new types in a way that it will consider the file
extensions when the new types are not registered. It therefore would have
prevented a regression for us.
Backports are here: https://bugs.openjdk.java.net/browse/JDK-8273655
> FileSystemManager.createFileSystem(FileObject) fails on Gzip files.
> ---
>
> Key: VFS-770
> URL: https://issues.apache.org/jira/browse/VFS-770
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.6.0
> Environment: Both Java 8 and Java 13
>Reporter: Thomas BELOT
>Priority: Major
> Fix For: 2.10.0
>
>
> Stack trace :
> {noformat}
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException: Could
> not find a file provider that can handle file "file:///C:/DIR/00-test.gz".
> at
> org.apache.commons.vfs2.FileSystemException.requireNonNull(FileSystemException.java:87)
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.createFileSystem(DefaultFileSystemManager.java:909)
> at MyClass.test(MyClass.java:77)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at one.util.streamex.AbstractStreamEx.forEach(AbstractStreamEx.java:314)
> at MyClass.main(MyClass.java:45)
> {noformat}
> Caused by :
> [fileNameMap.getContentTypeFor(name);|https://gitbox.apache.org/repos/asf?p=commons-vfs.git;a=blob;f=commons-vfs2/src/main/java/org/apache/commons/vfs2/impl/FileContentInfoFilenameFactory.java;h=2888ff6545055c8d00cbd73412671d17560b2592;hb=HEAD#l42]
> which delegates content type resolution to Java's
> URLConnection.getFileNameMap() which in turn resolves GZip to a generic
> application/octet-stream hence leading to this exception.
> If the resolution had triggered a null or an application/x-gzip it would not
> have lead to this problem.
> Forcing resolution with fsManager.createFileSystem("gz",f) is a workaround
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (VFS-818) SftpFileObject.isReadable may return false for user root
[
https://issues.apache.org/jira/browse/VFS-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524580#comment-17524580
]
Bernd Eckenfels commented on VFS-818:
-
I don’t think this can be actually won, there is no way for a client to deduce
permissions for all semantics which could be at play here (think ACL, root
squash, readonly filesystem, SELinux, etc). Therefore (again) I find it not a
good idea to try to deduce access errors, instead we should just try the
operation.
Having said that people should really not use root user and I would not
encourage it by adding a specific workaround for it. Having said that.. it
probably also does not hurt, it’s not a security critical permission
enforcement.
> SftpFileObject.isReadable may return false for user root
>
>
> Key: VFS-818
> URL: https://issues.apache.org/jira/browse/VFS-818
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Christian Nüssgens
>Priority: Minor
>
> I got the following exception when trying to call
> {{org.apache.commons.vfs2.FileContent.getRandomAccessContent(READ)}}
> {noformat}
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException: File
> "sftp://root:***@host/var/log/myFile.log; is not readable.
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getRandomAccessContent(AbstractFileObject.java:1340)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getRandomAccessContent(DefaultFileContent.java:373)
> at Main.main(Main.java:<>)
> {noformat}
> The problem seems to be located in the PosixPermissions check introduced with
> this commit:
> https://github.com/apache/commons-vfs/commit/3b73cc3a9bba6c25520d20f83d7f68f69e2ba911
> (VFS-405)
> See example code
> {code:java}
> import static org.apache.commons.vfs2.util.RandomAccessMode.READ;
> import org.apache.commons.vfs2.FileObject;
> import org.apache.commons.vfs2.FileSystemManager;
> import org.apache.commons.vfs2.FileSystemOptions;
> import org.apache.commons.vfs2.RandomAccessContent;
> import org.apache.commons.vfs2.VFS;
> import org.apache.commons.vfs2.provider.sftp.SftpFileSystemConfigBuilder;
> public class Main{
> public static void main(String[] args) throws Exception {
> FileSystemManager fsManager = VFS.getManager();
> FileSystemOptions opts = new FileSystemOptions();
> SftpFileSystemConfigBuilder.getInstance().setStrictHostKeyChecking(opts,
> "no");
> SftpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(opts, false);
> String fileUri = "sftp://root:pw@host/var/log/myFile.log;;
> // my file has following permissions:
> // root@host:/var/log# ls -lah myFile.log
> // -rw-r- 1 tomcat tomcat 8.5M Apr 19 15:02 myFile.log
> FileObject myFile = fsManager.resolveFile(fileUri, opts);
> RandomAccessContent randomAccessContent =
> myFile.getContent().getRandomAccessContent(READ);
> System.out.println(randomAccessContent.length());
> }
> }
> {code}
> As one can see user tomcat can read, group tomcat can read. But not
> _everyone_ is allowed to read. In my case i authenticated with user {{root}}
> ({{uid=0, gid=0}}).
> In that case
> https://github.com/apache/commons-vfs/blob/master/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileObject.java#L456-L476
> creates PosixPermissions with the _hints_ not owner, not in group. The
> method {{org.apache.commons.vfs2.util.PosixPermissions.isReadable()}} will
> than just check if _anyone_ (/other) is able to read the file, which is not
> granted (mask is {{0640}})
> I guess there should be an extra check for {{root}} which is always granted
> access.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IO-766) ValidatingObjectInputStream
[ https://issues.apache.org/jira/browse/IO-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522377#comment-17522377 ] Bernd Eckenfels commented on IO-766: BTW The `[L` is the prefix for Arrays of reference types, it is followed by the member classname and a ;. That’s pretty normal for Java you see it all over the place when dumping for example method signatures. Other `[` variants are for the primitive arrays. > ValidatingObjectInputStream > --- > > Key: IO-766 > URL: https://issues.apache.org/jira/browse/IO-766 > Project: Commons IO > Issue Type: Bug > Environment: Java 8, Ubuntu 16.04 LTS, Eclipse Neon, Apache Commons > IO 2.11.0 >Reporter: Jonathon Nicholas Sanders >Priority: Major > Attachments: .checksum.md5, Unit Test Case_20220413.zip > > > I have been using ValidatingObjectInputStream and found a bug. > > It appears when you have an ArrayList of String it fails to validate the > String.class ( [Ljava.lang.String; ) because somehow some extra data in the > full class name causes an error. Currently I have no work around, I could > edit the source, and see if I can hunt down the bug myself, but I don't think > my project manager would care for that option if it takes me too much time, > the other is also not ideal and that is avoid using ArrayList but > the again, this could be an issue for any ArrayList of Classes. > > I am using Oracle Java 8 on Ubuntu 16.04 LTS, here is my stacktrace. I have > removed references to my classes for the sake of confidentiality. > > Apr 08, 2022 3:07:33 PM gov.jdaccs.views.__ openConfiguration > SEVERE: Class name not accepted: [Ljava.lang.String; > java.io.InvalidClassException: Class name not accepted: [Ljava.lang.String; > at > org.apache.commons.io.serialization.ValidatingObjectInputStream.invalidClassNameFound(ValidatingObjectInputStream.java:95) > at > org.apache.commons.io.serialization.ValidatingObjectInputStream.validateClassName(ValidatingObjectInputStream.java:82) > at > org.apache.commons.io.serialization.ValidatingObjectInputStream.resolveClass(ValidatingObjectInputStream.java:100) > at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1859) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1745) > at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1921) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1561) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2278) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2202) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2060) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1567) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:427) > at java.util.ArrayList.readObject(ArrayList.java:797) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2169) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2060) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1567) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2278) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2202) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2060) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1567) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2278) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2202) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2060) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1567) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:427) > at gov.jdaccs.config.__.readConfiguration(__.java:74) > at gov.jdaccs.views.__.openConfiguration(__.java:511) > at gov.jdaccs.views.__.loadDefaults(__.java:757) > at gov.jdaccs.views.__.createNewConfiguration(__.java:2508) > at gov.jdaccs.views.__.(__.java:262) > at gov.jdaccs.views.__.main(_.java:2534) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOGGING-180) Upgrade commons logging log4j dependency versions to 2.17.0 and above
[ https://issues.apache.org/jira/browse/LOGGING-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507695#comment-17507695 ] Bernd Eckenfels commented on LOGGING-180: - Some humans and tools wrongly flag 1.2 as affected by the 2.x CVEs, but that’s not the actual problem. The actual problem is that 1.2.17 has many known/unresolved CVEs on its own (remotely related to log4shell). That could be fixed with reload4j 1.2.18 or by migrating to log4j 2 (which is funny enough strange to migrate to a branch which caused the biggest security incident in history in order to claim its more secure :) I think it is important to keep known CVEs out of toolchains, even when it is only a build dependency. But it’s not a high prio, especially if it is 10 dependencies deep… > Upgrade commons logging log4j dependency versions to 2.17.0 and above > - > > Key: LOGGING-180 > URL: https://issues.apache.org/jira/browse/LOGGING-180 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1, 1.2 >Reporter: Swyrik Thupili >Priority: Major > > Please update the log4j 2 version to the log4j 2.17.0 and above. As the > current versions are susceptible to > [CVE-2021-44832|https://github.com/advisories/GHSA-8489-44mv-ggj8] Security > Vulnerability. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOGGING-180) Upgrade commons logging log4j dependency versions to 2.17.0 and above
[ https://issues.apache.org/jira/browse/LOGGING-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482957#comment-17482957 ] Bernd Eckenfels commented on LOGGING-180: - I wonder if we could use reload4j ;) > Upgrade commons logging log4j dependency versions to 2.17.0 and above > - > > Key: LOGGING-180 > URL: https://issues.apache.org/jira/browse/LOGGING-180 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1, 1.2 >Reporter: Swyrik Thupili >Priority: Major > > Please update the log4j 2 version to the log4j 2.17.0 and above. As the > current versions are susceptible to > [CVE-2021-44832|https://github.com/advisories/GHSA-8489-44mv-ggj8] Security > Vulnerability. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CLI-310) Purge release version 20040117.000000 from Maven Central
[
https://issues.apache.org/jira/browse/CLI-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17432861#comment-17432861
]
Bernd Eckenfels commented on CLI-310:
-
I dont think OSSRH is the right place, there should be no delete propagation to
central. However it is certainly good to also consult OSSRH and central ops. I
can do that later today.
> Purge release version 20040117.00 from Maven Central
>
>
> Key: CLI-310
> URL: https://issues.apache.org/jira/browse/CLI-310
> Project: Commons CLI
> Issue Type: Task
>Reporter: Markus Spann
>Priority: Minor
>
> How did commons-cli "release version" 20040117.00 make it into Maven
> Central?
> It's been there for as long as I can remember.
> It would not bother any of us if this version did not always show up as the
> most recent/latest/bleeding edge release. Even though it's ancient and noone
> would want to use it of course.
> This effect is due to this version not following the commons-cli version
> scheme and due to the way Maven sorts version strings.
> A small use case to illustrate:
>
> {code:java}
> mvn versions:display-dependency-updates
> {code}
>
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO] commons-cli:commons-cli ... 1.4 -> 20040117.00
> {code}
> I understand that purging release artifacts from Central may not be simple.
> Yet it would be so much appreciated if someone with the corresponding
> know-how and access could take care of it. Thanks a million!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CLI-310) Purge release version 20040117.000000 from Maven Central
[
https://issues.apache.org/jira/browse/CLI-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17432266#comment-17432266
]
Bernd Eckenfels commented on CLI-310:
-
Normally I would agree that central can’t be modified, but in this case there
is no signature present, so it’s really risky that it gets preferred by maven
resolver. Should we raise a sonatype-ops issue and ask for their oppinion.
Having said that.. should maven have a device for centrally managed deny-lists?
> Purge release version 20040117.00 from Maven Central
>
>
> Key: CLI-310
> URL: https://issues.apache.org/jira/browse/CLI-310
> Project: Commons CLI
> Issue Type: Task
>Reporter: Markus Spann
>Priority: Minor
>
> How did commons-cli "release version" 20040117.00 make it into Maven
> Central?
> It's been there for as long as I can remember.
> It would not bother any of us if this version did not always show up as the
> most recent/latest/bleeding edge release. Even though it's ancient and noone
> would want to use it of course.
> This effect is due to this version not following the commons-cli version
> scheme and due to the way Maven sorts version strings.
> A small use case to illustrate:
>
> {code:java}
> mvn versions:display-dependency-updates
> {code}
>
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO] commons-cli:commons-cli ... 1.4 -> 20040117.00
> {code}
> I understand that purging release artifacts from Central may not be simple.
> Yet it would be so much appreciated if someone with the corresponding
> know-how and access could take care of it. Thanks a million!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FILEUPLOAD-341) Move exceptions out of .impl package
[ https://issues.apache.org/jira/browse/FILEUPLOAD-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved FILEUPLOAD-341. Fix Version/s: 2.0 Resolution: Fixed Do we need an update guide for the 2.0 with all the incompatible changes, or add a section to the README? If so, is that the last restructuring which makes sense to avoid another major version? > Move exceptions out of .impl package > > > Key: FILEUPLOAD-341 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-341 > Project: Commons FileUpload > Issue Type: Wish >Affects Versions: 2.0 >Reporter: Martin Tzvetanov Grigorov >Assignee: Jochen Wiedmann >Priority: Minor > Fix For: 2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > With FILEUPLOAD-340 commons-fileupload2 now provides a module-info.class that > exports all packages but org.apache.commons.fileupload2.impl. > > Would it be OK to move all **Exception classes to the parent package so that > they are visible by users ? > **Impl classes should stay in org.apache.commons.fileupload2.impl! > > In Apache Wicket we use few of the exception classes to report specific > errors: > * > [https://github.com/apache/wicket/blob/43bc9b112ee43fac80f830632415cd8060b3d1a2/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/MultipartServletWebRequestImpl.java#L505] > * > [https://github.com/apache/wicket/blob/270a5a43970cd975539331b21a34bd83a59c9c39/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java#L1504] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (VFS-773) Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html" because it is a relative path, and no base URI was provided.
[
https://issues.apache.org/jira/browse/VFS-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels closed VFS-773.
---
> Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html;
> because it is a relative path, and no base URI was provided.
> --
>
> Key: VFS-773
> URL: https://issues.apache.org/jira/browse/VFS-773
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.6.0
> Environment: Google Cloud Engine instance with default firewall
> settings
>Reporter: Max Maeder
>Priority: Major
> Original Estimate: 2m
> Remaining Estimate: 2m
>
> I've been pulling my hair out over this issue, I've searched the interwebs
> and this issue tracker for someone having a similar issue, but to no avail.
> Every time I run the following code, I get this error:
>
> {code:java}
> org.apache.commons.vfs2.FileSystemException: Could not find file with URI
> "sftp://max_s_maeder@35.232.72.5:22/hi.html; because it is a relative path,
> and no base URI was provided.
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.FileSystemException.requireNonNull(FileSystemException.java:87)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:734)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:683)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:638)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.SFTPUploader.uploadFile(SFTPUploader.java:55)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.FTPUploader.uploadFile(FTPUploader.java:37)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.UploadThread.run(UploadThread.java:96)
> [01:58:12] [Thread-14/WARN]:at
> java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>
>
> {code:java}
> package ratismal.drivebackup.ftp;
> import org.apache.commons.vfs2.FileObject;import
> org.apache.commons.vfs2.FileSystemManager;import org.apache.commons.vfs2.VFS;
> import ratismal.drivebackup.config.Config;import
> ratismal.drivebackup.util.MessageUtil;
> import java.io.File;import java.util.*;
> public class SFTPUploader {
> public static void uploadFile() throws Exception {FileSystemManager
> manager = VFS.getManager();
> FileObject remoteFolder =
> manager.resolveFile("sftp://max_s_maeder@35.232.72.5:22/hi.html;);
> remoteFolder.close(); }}
> {code}
> I'm sorry if this is the wrong place to ask.
> Also, the credentials above aren't going to get you into my server ;)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (VFS-773) Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html" because it is a relative path, and no base URI was provided.
[
https://issues.apache.org/jira/browse/VFS-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels resolved VFS-773.
-
Resolution: Not A Problem
> Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html;
> because it is a relative path, and no base URI was provided.
> --
>
> Key: VFS-773
> URL: https://issues.apache.org/jira/browse/VFS-773
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.6.0
> Environment: Google Cloud Engine instance with default firewall
> settings
>Reporter: Max Maeder
>Priority: Major
> Original Estimate: 2m
> Remaining Estimate: 2m
>
> I've been pulling my hair out over this issue, I've searched the interwebs
> and this issue tracker for someone having a similar issue, but to no avail.
> Every time I run the following code, I get this error:
>
> {code:java}
> org.apache.commons.vfs2.FileSystemException: Could not find file with URI
> "sftp://max_s_maeder@35.232.72.5:22/hi.html; because it is a relative path,
> and no base URI was provided.
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.FileSystemException.requireNonNull(FileSystemException.java:87)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:734)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:683)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:638)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.SFTPUploader.uploadFile(SFTPUploader.java:55)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.FTPUploader.uploadFile(FTPUploader.java:37)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.UploadThread.run(UploadThread.java:96)
> [01:58:12] [Thread-14/WARN]:at
> java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>
>
> {code:java}
> package ratismal.drivebackup.ftp;
> import org.apache.commons.vfs2.FileObject;import
> org.apache.commons.vfs2.FileSystemManager;import org.apache.commons.vfs2.VFS;
> import ratismal.drivebackup.config.Config;import
> ratismal.drivebackup.util.MessageUtil;
> import java.io.File;import java.util.*;
> public class SFTPUploader {
> public static void uploadFile() throws Exception {FileSystemManager
> manager = VFS.getManager();
> FileObject remoteFolder =
> manager.resolveFile("sftp://max_s_maeder@35.232.72.5:22/hi.html;);
> remoteFolder.close(); }}
> {code}
> I'm sorry if this is the wrong place to ask.
> Also, the credentials above aren't going to get you into my server ;)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (VFS-773) Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html" because it is a relative path, and no base URI was provided.
[
https://issues.apache.org/jira/browse/VFS-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376739#comment-17376739
]
Bernd Eckenfels edited comment on VFS-773 at 7/7/21, 5:33 PM:
--
The error most likely means the `sftp` scheme/provider is not registered, Since
you are using the default manager this is normally caused by missing
dependencies. You need at least JSch, commons-logging and commons-Lang on the
classpath. I think the easiest to debug this is to actually try to instantiate
the provider yourself.
was (Author: b.eckenfels):
The error most likely means the `sftp` scheme/provider is not registered, Since
you are using the default manager this is normally caused by missing
dependencies. You need at least JSch, commons-logging and commons-Io on the
classpath. I think the easiest to debug this is to actually try to instantiate
the provider yourself.
> Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html;
> because it is a relative path, and no base URI was provided.
> --
>
> Key: VFS-773
> URL: https://issues.apache.org/jira/browse/VFS-773
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.6.0
> Environment: Google Cloud Engine instance with default firewall
> settings
>Reporter: Max Maeder
>Priority: Major
> Original Estimate: 2m
> Remaining Estimate: 2m
>
> I've been pulling my hair out over this issue, I've searched the interwebs
> and this issue tracker for someone having a similar issue, but to no avail.
> Every time I run the following code, I get this error:
>
> {code:java}
> org.apache.commons.vfs2.FileSystemException: Could not find file with URI
> "sftp://max_s_maeder@35.232.72.5:22/hi.html; because it is a relative path,
> and no base URI was provided.
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.FileSystemException.requireNonNull(FileSystemException.java:87)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:734)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:683)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:638)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.SFTPUploader.uploadFile(SFTPUploader.java:55)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.FTPUploader.uploadFile(FTPUploader.java:37)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.UploadThread.run(UploadThread.java:96)
> [01:58:12] [Thread-14/WARN]:at
> java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>
>
> {code:java}
> package ratismal.drivebackup.ftp;
> import org.apache.commons.vfs2.FileObject;import
> org.apache.commons.vfs2.FileSystemManager;import org.apache.commons.vfs2.VFS;
> import ratismal.drivebackup.config.Config;import
> ratismal.drivebackup.util.MessageUtil;
> import java.io.File;import java.util.*;
> public class SFTPUploader {
> public static void uploadFile() throws Exception {FileSystemManager
> manager = VFS.getManager();
> FileObject remoteFolder =
> manager.resolveFile("sftp://max_s_maeder@35.232.72.5:22/hi.html;);
> remoteFolder.close(); }}
> {code}
> I'm sorry if this is the wrong place to ask.
> Also, the credentials above aren't going to get you into my server ;)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (VFS-773) Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html" because it is a relative path, and no base URI was provided.
[
https://issues.apache.org/jira/browse/VFS-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376739#comment-17376739
]
Bernd Eckenfels commented on VFS-773:
-
The error most likely means the `sftp` scheme/provider is not registered, Since
you are using the default manager this is normally caused by missing
dependencies. You need at least JSch, commons-logging and commons-Io on the
classpath. I think the easiest to debug this is to actually try to instantiate
the provider yourself.
> Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html;
> because it is a relative path, and no base URI was provided.
> --
>
> Key: VFS-773
> URL: https://issues.apache.org/jira/browse/VFS-773
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.6.0
> Environment: Google Cloud Engine instance with default firewall
> settings
>Reporter: Max Maeder
>Priority: Major
> Original Estimate: 2m
> Remaining Estimate: 2m
>
> I've been pulling my hair out over this issue, I've searched the interwebs
> and this issue tracker for someone having a similar issue, but to no avail.
> Every time I run the following code, I get this error:
>
> {code:java}
> org.apache.commons.vfs2.FileSystemException: Could not find file with URI
> "sftp://max_s_maeder@35.232.72.5:22/hi.html; because it is a relative path,
> and no base URI was provided.
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.FileSystemException.requireNonNull(FileSystemException.java:87)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:734)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:683)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:638)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.SFTPUploader.uploadFile(SFTPUploader.java:55)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.FTPUploader.uploadFile(FTPUploader.java:37)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.UploadThread.run(UploadThread.java:96)
> [01:58:12] [Thread-14/WARN]:at
> java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>
>
> {code:java}
> package ratismal.drivebackup.ftp;
> import org.apache.commons.vfs2.FileObject;import
> org.apache.commons.vfs2.FileSystemManager;import org.apache.commons.vfs2.VFS;
> import ratismal.drivebackup.config.Config;import
> ratismal.drivebackup.util.MessageUtil;
> import java.io.File;import java.util.*;
> public class SFTPUploader {
> public static void uploadFile() throws Exception {FileSystemManager
> manager = VFS.getManager();
> FileObject remoteFolder =
> manager.resolveFile("sftp://max_s_maeder@35.232.72.5:22/hi.html;);
> remoteFolder.close(); }}
> {code}
> I'm sorry if this is the wrong place to ask.
> Also, the credentials above aren't going to get you into my server ;)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362034#comment-17362034
]
Bernd Eckenfels commented on NET-408:
-
You can use a explicite `––add–opens` this will work besides the removed
`—illegal-access` option in java 17. but it’s really strange that we get no api
support in this area for years
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip,
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (NET-686) Most files aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221380#comment-17221380 ] Bernd Eckenfels edited comment on NET-686 at 10/27/20, 12:45 PM: - Since you get the same problem with sockets I would say its not related to commons-net but a problem with your -handy-mobile or -handy-mobile network or server. Maybe using TLS will help? or a vpn? some providers really do strange things to mobile traffic. was (Author: ecki): Since you get the same problem with sockets I would say its not related to commons-net but a problem with your handy or handy network or server. Maybe using TLS will help? or a vpn? some providers really do strange things to mobile traffic. > Most files aren't downloaded completely from an FTP server > -- > > Key: NET-686 > URL: https://issues.apache.org/jira/browse/NET-686 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6, 3.7.2 > Environment: Win 10 > Java 8 > Android Studio 3.6.1 (min SDK 24, target SDK 27) >Reporter: JRRR >Priority: Major > Attachments: 2a-original.png, 2b-corrupt.png, 2c-corrupt.png, > 5a-original.jpg, 5b-corrupt.jpg, 5c-corrupt.jpg, DownloadProblem.java > > > About a month ago I opened another > [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because > it wasn't reproducible with macOS and a public FTP server. > Short summary: Downloading files from an FTP server results in these files > randomly missing bytes. It looks like the download always "completes" and > there are no error messages/exceptions but random bytes in random files are > simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe > 40, bytes smaller than the original), and are then also visibly corrupt, than > text files (usually only 2-3 bytes smaller, rarely more). > I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK > 24, target SDK 27), which I'm testing with FTP servers in the same network > (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what > method in the library I use (retrieveFile, retrieveFileStream, > sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a > single file that's corrupted. > I also tested the same code with public servers and even though I didn't have > a lot of time because those servers regularely delete uploaded files, I never > experienced said problem with them. > I even wrote my own mini-library (just for login/logout and download) using > Java's default "Socket" but I still had the same problem on Android Studio's > simulator/a real device. BUT: When I used the same code to create a small > Windows/Swing/Java app, there were no more corrupted files. > It looks like this bug is only affecting a very specific combination of > OS,...: > Android (emulator/real device) + Java (8) + FTP server in the same network > (accessed via IP) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NET-686) Most files aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221380#comment-17221380 ] Bernd Eckenfels commented on NET-686: - Since you get the same problem with sockets I would say its not related to commons-net but a problem with your handy or handy network or server. Maybe using TLS will help? or a vpn? some providers really do strange things to mobile traffic. > Most files aren't downloaded completely from an FTP server > -- > > Key: NET-686 > URL: https://issues.apache.org/jira/browse/NET-686 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6, 3.7.2 > Environment: Win 10 > Java 8 > Android Studio 3.6.1 (min SDK 24, target SDK 27) >Reporter: JRRR >Priority: Major > Attachments: 2a-original.png, 2b-corrupt.png, 2c-corrupt.png, > 5a-original.jpg, 5b-corrupt.jpg, 5c-corrupt.jpg, DownloadProblem.java > > > About a month ago I opened another > [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because > it wasn't reproducible with macOS and a public FTP server. > Short summary: Downloading files from an FTP server results in these files > randomly missing bytes. It looks like the download always "completes" and > there are no error messages/exceptions but random bytes in random files are > simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe > 40, bytes smaller than the original), and are then also visibly corrupt, than > text files (usually only 2-3 bytes smaller, rarely more). > I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK > 24, target SDK 27), which I'm testing with FTP servers in the same network > (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what > method in the library I use (retrieveFile, retrieveFileStream, > sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a > single file that's corrupted. > I also tested the same code with public servers and even though I didn't have > a lot of time because those servers regularely delete uploaded files, I never > experienced said problem with them. > I even wrote my own mini-library (just for login/logout and download) using > Java's default "Socket" but I still had the same problem on Android Studio's > simulator/a real device. BUT: When I used the same code to create a small > Windows/Swing/Java app, there were no more corrupted files. > It looks like this bug is only affecting a very specific combination of > OS,...: > Android (emulator/real device) + Java (8) + FTP server in the same network > (accessed via IP) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-504) Deprecated of all IOUtils.closeQuietly() methods and use try-with-resources internally
[ https://issues.apache.org/jira/browse/IO-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17210371#comment-17210371 ] Bernd Eckenfels commented on IO-504: I agree, should not be deprecated, it is enough if Javadoc points to „better“ alternatives Besides the mentioned producer case it’s also useful if very specific error handling and rewinding is needed. > Deprecated of all IOUtils.closeQuietly() methods and use try-with-resources > internally > -- > > Key: IO-504 > URL: https://issues.apache.org/jira/browse/IO-504 > Project: Commons IO > Issue Type: Wish >Reporter: Christian Schulte >Priority: Major > Fix For: 2.6 > > Attachments: IO-504.patch, IO-504.patch > > > As soon as 'commons-io' is targetted at Java 7, all 'IOUtils.closeQuietly' > methods should be deprecated and people should be told to use the > try-with-resources statement. Those methods are way to error prone and used > incorrectly almost everywhere. If 'commons-io' has '-target 1.7', keeping > those methods makes no sense anymore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-766) SftpClientFactory hangs at FileSystemManager.resolveFile(...)
[
https://issues.apache.org/jira/browse/VFS-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201591#comment-17201591
]
Bernd Eckenfels commented on VFS-766:
-
Release matters are discussed on the developers mailing list. There are no
fixed release schedules, it depends on volunteer availability. Historic dates
should be visible in the changes.xml metadata inside the repository
https://github.com/apache/commons-vfs/blob/master/src/changes/changes.xml some
stuff is also in the wiki but not very active as the canonical release happens
on the distribution servers and is announced by the mailing list.
> SftpClientFactory hangs at FileSystemManager.resolveFile(...)
> -
>
> Key: VFS-766
> URL: https://issues.apache.org/jira/browse/VFS-766
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.5.0, 2.6.0
>Reporter: Jasper Teng
>Priority: Critical
> Fix For: 2.7.0
>
>
> Issue: When trying to sftp, it hangs inside
> FileSystemManager.resolveFile(...).
>
> Libs in classpath used for testing:
> * commons-vfs2-2.6.0.jar / commons-vfs2-2.5.0.jar
> * commons-vfs2-jackrabbit2-2.5.0.jar
> * jackrabbit-webdav-2.20.0.jar
>
> Issue Log file (2.5.0 + Server X):
> {noformat}
> 25 Mar, 20:00:37,825 INFO main [SftpClientFactory$JSchLogger.log()]
> [65017ms] Connection established
> 25 Mar, 20:00:38,013 INFO main [SftpClientFactory$JSchLogger.log()]
> [65205ms] Remote version string: SSH-2.0-ProVide
> 25 Mar, 20:00:38,017 INFO main [SftpClientFactory$JSchLogger.log()]
> [65209ms] Local version string: SSH-2.0-JSCH-0.1.52
> ...snip...
> 25 Mar, 20:01:02,802 INFO main [SftpClientFactory$JSchLogger.log()]
> [89994ms] kex: server->client aes128-ctr hmac-md5 none
> 25 Mar, 20:01:02,809 INFO main [SftpClientFactory$JSchLogger.log()]
> [90001ms] kex: client->server aes128-ctr hmac-md5 none
> 25 Mar, 20:01:06,359 INFO main [SftpClientFactory$JSchLogger.log()]
> [93551ms] SSH_MSG_KEXDH_INIT sent
> 25 Mar, 20:01:06,363 INFO main [SftpClientFactory$JSchLogger.log()]
> [93555ms] expecting SSH_MSG_KEXDH_REPLY
> 25 Mar, 20:01:10,410 INFO main [SftpClientFactory$JSchLogger.log()]
> [97602ms] ssh_rsa_verify: signature true
> 25 Mar, 20:01:10,427 WARN main [SftpClientFactory$JSchLogger.log()]
> [97619ms] Permanently added 'mask.mask.mask' (RSA) to the list of known hosts.
> 25 Mar, 20:01:10,438 INFO main [SftpClientFactory$JSchLogger.log()]
> [97630ms] SSH_MSG_NEWKEYS sent
> 25 Mar, 20:01:10,625 INFO main [SftpClientFactory$JSchLogger.log()]
> [97817ms] SSH_MSG_NEWKEYS received
> 25 Mar, 20:01:10,709 INFO main [SftpClientFactory$JSchLogger.log()]
> [97901ms] SSH_MSG_SERVICE_REQUEST sent
> 25 Mar, 20:01:10,897 INFO main [SftpClientFactory$JSchLogger.log()]
> [98089ms] SSH_MSG_SERVICE_ACCEPT received
> 25 Mar, 20:01:11,098 INFO main [SftpClientFactory$JSchLogger.log()]
> [98290ms] Authentications that can continue:
> publickey,keyboard-interactive,password
> 25 Mar, 20:01:11,102 INFO main [SftpClientFactory$JSchLogger.log()]
> [98294ms] Next authentication method: publickey
> 25 Mar, 20:01:11,114 INFO main [SftpClientFactory$JSchLogger.log()]
> [98306ms] Authentications that can continue: password
> 25 Mar, 20:01:11,119 INFO main [SftpClientFactory$JSchLogger.log()]
> [98311ms] Next authentication method: password
> 25 Mar, 20:01:11,735 INFO main [SftpClientFactory$JSchLogger.log()]
> [98927ms] Authentication succeeded (password).{noformat}
>
> Issue Log file (2.6.0 + Server X):
> {noformat}
> 26 Mar, 09:42:07,781 INFO main [SftpClientFactory$JSchLogger.log()]
> [20400ms] Connection established
> 26 Mar, 09:42:07,971 INFO main [SftpClientFactory$JSchLogger.log()]
> [20590ms] Remote version string: SSH-2.0-ProVide
> 26 Mar, 09:42:07,975 INFO main [SftpClientFactory$JSchLogger.log()]
> [20594ms] Local version string: SSH-2.0-JSCH-0.1.52
> ...snip...
> 26 Mar, 09:42:33,250 INFO main [SftpClientFactory$JSchLogger.log()]
> [45869ms] kex: server->client aes128-ctr hmac-md5 none
> 26 Mar, 09:42:33,258 INFO main [SftpClientFactory$JSchLogger.log()]
> [45877ms] kex: client->server aes128-ctr hmac-md5 none
> 26 Mar, 09:42:36,710 INFO main [SftpClientFactory$JSchLogger.log()]
> [49329ms] SSH_MSG_KEXDH_INIT sent
> 26 Mar, 09:42:36,716 INFO main [SftpClientFactory$JSchLogger.log()]
> [49335ms] expecting SSH_MSG_KEXDH_REPLY
> 26 Mar, 09:42:40,635 INFO main [SftpClientFactory$JSchLogger.log()]
> [53254ms] ssh_rsa_verify: signature true
> 26 Mar, 09:42:40,653 INFO main [SftpClientFactory$JSchLogger.log()]
> [53272ms] Host 'mask.mask.mask' is known and matches the RSA host key
> 26 Mar, 09:42:40,660 INFO main [SftpClientFactory$JSchLogger.log()]
> [53279ms] SSH_MSG_NEWKEYS sent
> 26 Mar, 09:42:40,845 INFO main [SftpClientFactory$JSchLogger.log()]
> [53464ms]
[jira] [Commented] (NET-686) Most files aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169901#comment-17169901 ] Bernd Eckenfels commented on NET-686: - Can you provide a binary difference what exactly is wrong or provide a Testfile and it's corrupt result? Is the same test file always broken when you request it multiple times? Btw you don't need the buffered input stream if you read with larger buffer. I would move the setFileType before the retrieve (after the list files). > Most files aren't downloaded completely from an FTP server > -- > > Key: NET-686 > URL: https://issues.apache.org/jira/browse/NET-686 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Win 10 > Java 8 > Android Studio 3.6.1 (min SDK 24, target SDK 27) >Reporter: JRRR >Priority: Major > Attachments: DownloadProblem.java > > > About a month ago I opened another > [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because > it wasn't reproducible with macOS and a public FTP server. > Short summary: Downloading files from an FTP server results in these files > randomly missing bytes. It looks like the download always "completes" and > there are no error messages/exceptions but random bytes in random files are > simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe > 40, bytes smaller than the original), and are then also visibly corrupt, than > text files (usually only 2-3 bytes smaller, rarely more). > I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK > 24, target SDK 27), which I'm testing with FTP servers in the same network > (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what > method in the library I use (retrieveFile, retrieveFileStream, > sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a > single file that's corrupted. > I also tested the same code with public servers and even though I didn't have > a lot of time because those servers regularely delete uploaded files, I never > experienced said problem with them. > I even wrote my own mini-library (just for login/logout and download) using > Java's default "Socket" but I still had the same problem on Android Studio's > simulator/a real device. BUT: When I used the same code to create a small > Windows/Swing/Java app, there were no more corrupted files. > It looks like this bug is only affecting a very specific combination of > OS,...: > Android (emulator/real device) + Java (8) + FTP server in the same network > (accessed via IP) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-575) org.apache.commons.vfs2.FileSystemException: Could not close the output stream
[ https://issues.apache.org/jira/browse/VFS-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17135662#comment-17135662 ] Bernd Eckenfels commented on VFS-575: - I think if the bug is not closed it still exists. Can you provide more details and logs, maybe it helps someone to write a fix. > org.apache.commons.vfs2.FileSystemException: Could not close the output stream > -- > > Key: VFS-575 > URL: https://issues.apache.org/jira/browse/VFS-575 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: Linux, Weblogic >Reporter: Arajit >Priority: Major > > Hi Team, > I am using VFS 2.0 for implementing SFTP for my application. I have a single > Thread which actually picks up the file and do SFTP. 98% of the time it > works. But I have observed there are few cases where SFTP is getting failed > with below exception.. > Caused by: org.apache.commons.vfs2.FileSystemException: Could not close the > output stream for file "sftp://***/Test.csv;. > [null,null]at > org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:694) > [null,null]at > org.apache.commons.vfs2.FileUtil.copyContent(FileUtil.java:118) > [null,null]at > org.apache.commons.vfs2.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:1053) > [null,null]... 3 more > Caused by: java.io.IOException: inputstream is closed > [null,null]at com.jcraft.jsch.ChannelSftp.fill(ChannelSftp.java:2884) > [null,null]at com.jcraft.jsch.ChannelSftp.header(ChannelSftp.java:2908) > [null,null]at > com.jcraft.jsch.ChannelSftp.checkStatus(ChannelSftp.java:2446) > [null,null]at > com.jcraft.jsch.ChannelSftp._sendCLOSE(ChannelSftp.java:2465) > [null,null]at > com.jcraft.jsch.ChannelSftp.access$400(ChannelSftp.java:36) > [null,null]at com.jcraft.jsch.ChannelSftp$1.close(ChannelSftp.java:854) > [null,null]at > java.io.FilterOutputStream.close(FilterOutputStream.java:143) > [null,null]at > org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:56) > [null,null]at > java.io.FilterOutputStream.close(FilterOutputStream.java:143) > [null,null]at > org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:56) > [null,null]at > org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:690) > [null,null]... 5 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-771) SFTP multiple get bad performances if copyFrom() called after findFiles()
[
https://issues.apache.org/jira/browse/VFS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108615#comment-17108615
]
Bernd Eckenfels commented on VFS-771:
-
Just set the cache strategy to ON_DEMAND?
(Optimizations would be to avoid resolves, like some of the getChildren methods
do)
> SFTP multiple get bad performances if copyFrom() called after findFiles()
> -
>
> Key: VFS-771
> URL: https://issues.apache.org/jira/browse/VFS-771
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.4.1, 2.6.0
>Reporter: Rémi Villé
>Priority: Major
>
> Similar to VFS-698: if you call sftpFile.findFiles(selector) before
> localFile.copyFrom(sftpFile, selector) the second call reset file stats in
> the cache (in .AbstractFileSystem#resolveFile() =>
> {code:java}
> if
> (getFileSystemManager().getCacheStrategy().equals(CacheStrategy.ON_RESOLVE)) {
> file.refresh();
> }
> {code}
> )
> Then the stats are retrieved one by one which result in poor performances.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (BSF-45) Error trying to access a MongoDB collection under Apache BSF script
[
https://issues.apache.org/jira/browse/BSF-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051134#comment-17051134
]
Bernd Eckenfels commented on BSF-45:
hm, strangely i cant edit this issue. I would close it, since the beanshell
syntax is nothing BSF itself can/wants to change. Thanks for responding,
Kleyson, if you can close it as invalid that would be fine.
> Error trying to access a MongoDB collection under Apache BSF script
> ---
>
> Key: BSF-45
> URL: https://issues.apache.org/jira/browse/BSF-45
> Project: Commons BSF
> Issue Type: Bug
> Components: BSF-2.x
>Affects Versions: BSF-2.4
> Environment: Java 8
> BSF 2.4.0
>Reporter: Kleyson Rios
>Priority: Major
> Attachments: exception.txt
>
>
> I'm trying to access a MongoDB collection from a java code to be 'eval' by
> BSF.
> I tried configure the MongoDB connection in both ways coding the driver
> connection and following the tutorial
> [https://mongodb.github.io/mongo-java-driver/3.10/driver/tutorials/jndi/] ,
> but in both cases the same error.
> Below the code to be executed by BSF:
>
> {code:java}
> import javax.naming.InitialContext;
> import com.mongodb.MongoClient;
> import com.mongodb.client.MongoDatabase;
> import com.mongodb.client.MongoCollection;
> import org.bson.Document;
> InitialContext cxt = new InitialContext();
> if ( cxt == null ) {
> throw new Exception("Uh oh -- no context!");
> }
> MongoClient ds = (MongoClient) cxt.lookup(
> "java:/comp/env/mongodb/MongoClient" );
> if ( ds == null ) {
> throw new Exception("Data source not found!");
> }
> MongoDatabase database = ds.getDatabase("ssp");
> //MongoCollection collection = database.getCollection("customer");
> {code}
>
> The code above runs fine, but If I uncomment the last line
> *MongoCollection collection = database.getCollection("customer")* ,
> the BSF throw a exception. See the attached *exception.txt* file.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (BSF-45) Error trying to access a MongoDB collection under Apache BSF script
[
https://issues.apache.org/jira/browse/BSF-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17049622#comment-17049622
]
Bernd Eckenfels edited comment on BSF-45 at 3/2/20 8:22 PM:
I think BeanShell does not support generics (<...>) you need to stick to Java
1.4 syntax.
{{MongoCollection collection = database.getCollection("customer");}}
was (Author: b.eckenfels):
I think BSF does not support generics (<...>) you need to stick to Java 1.4
syntax.
{{MongoCollection collection = database.getCollection("customer");}}
> Error trying to access a MongoDB collection under Apache BSF script
> ---
>
> Key: BSF-45
> URL: https://issues.apache.org/jira/browse/BSF-45
> Project: Commons BSF
> Issue Type: Bug
> Components: BSF-2.x
>Affects Versions: BSF-2.4
> Environment: Java 8
> BSF 2.4.0
>Reporter: Kleyson Rios
>Priority: Major
> Attachments: exception.txt
>
>
> I'm trying to access a MongoDB collection from a java code to be 'eval' by
> BSF.
> I tried configure the MongoDB connection in both ways coding the driver
> connection and following the tutorial
> [https://mongodb.github.io/mongo-java-driver/3.10/driver/tutorials/jndi/] ,
> but in both cases the same error.
> Below the code to be executed by BSF:
>
> {code:java}
> import javax.naming.InitialContext;
> import com.mongodb.MongoClient;
> import com.mongodb.client.MongoDatabase;
> import com.mongodb.client.MongoCollection;
> import org.bson.Document;
> InitialContext cxt = new InitialContext();
> if ( cxt == null ) {
> throw new Exception("Uh oh -- no context!");
> }
> MongoClient ds = (MongoClient) cxt.lookup(
> "java:/comp/env/mongodb/MongoClient" );
> if ( ds == null ) {
> throw new Exception("Data source not found!");
> }
> MongoDatabase database = ds.getDatabase("ssp");
> //MongoCollection collection = database.getCollection("customer");
> {code}
>
> The code above runs fine, but If I uncomment the last line
> *MongoCollection collection = database.getCollection("customer")* ,
> the BSF throw a exception. See the attached *exception.txt* file.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (BSF-45) Error trying to access a MongoDB collection under Apache BSF script
[
https://issues.apache.org/jira/browse/BSF-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17049622#comment-17049622
]
Bernd Eckenfels edited comment on BSF-45 at 3/2/20 8:21 PM:
I think BSF does not support generics (<...>) you need to stick to Java 1.4
syntax.
{{MongoCollection collection = database.getCollection("customer");}}
was (Author: b.eckenfels):
I think BSF does not support generics (`<...>`) you need to stick to Java 1.4
syntax.
> Error trying to access a MongoDB collection under Apache BSF script
> ---
>
> Key: BSF-45
> URL: https://issues.apache.org/jira/browse/BSF-45
> Project: Commons BSF
> Issue Type: Bug
> Components: BSF-2.x
>Affects Versions: BSF-2.4
> Environment: Java 8
> BSF 2.4.0
>Reporter: Kleyson Rios
>Priority: Major
> Attachments: exception.txt
>
>
> I'm trying to access a MongoDB collection from a java code to be 'eval' by
> BSF.
> I tried configure the MongoDB connection in both ways coding the driver
> connection and following the tutorial
> [https://mongodb.github.io/mongo-java-driver/3.10/driver/tutorials/jndi/] ,
> but in both cases the same error.
> Below the code to be executed by BSF:
>
> {code:java}
> import javax.naming.InitialContext;
> import com.mongodb.MongoClient;
> import com.mongodb.client.MongoDatabase;
> import com.mongodb.client.MongoCollection;
> import org.bson.Document;
> InitialContext cxt = new InitialContext();
> if ( cxt == null ) {
> throw new Exception("Uh oh -- no context!");
> }
> MongoClient ds = (MongoClient) cxt.lookup(
> "java:/comp/env/mongodb/MongoClient" );
> if ( ds == null ) {
> throw new Exception("Data source not found!");
> }
> MongoDatabase database = ds.getDatabase("ssp");
> //MongoCollection collection = database.getCollection("customer");
> {code}
>
> The code above runs fine, but If I uncomment the last line
> *MongoCollection collection = database.getCollection("customer")* ,
> the BSF throw a exception. See the attached *exception.txt* file.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (BSF-45) Error trying to access a MongoDB collection under Apache BSF script
[
https://issues.apache.org/jira/browse/BSF-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17049622#comment-17049622
]
Bernd Eckenfels edited comment on BSF-45 at 3/2/20 8:20 PM:
I think BSF does not support generics (`<...>`) you need to stick to Java 1.4
syntax.
was (Author: b.eckenfels):
I think BSF does not support generics (`<...>` you need to stick to Java 1.4
syntax.
> Error trying to access a MongoDB collection under Apache BSF script
> ---
>
> Key: BSF-45
> URL: https://issues.apache.org/jira/browse/BSF-45
> Project: Commons BSF
> Issue Type: Bug
> Components: BSF-2.x
>Affects Versions: BSF-2.4
> Environment: Java 8
> BSF 2.4.0
>Reporter: Kleyson Rios
>Priority: Major
> Attachments: exception.txt
>
>
> I'm trying to access a MongoDB collection from a java code to be 'eval' by
> BSF.
> I tried configure the MongoDB connection in both ways coding the driver
> connection and following the tutorial
> [https://mongodb.github.io/mongo-java-driver/3.10/driver/tutorials/jndi/] ,
> but in both cases the same error.
> Below the code to be executed by BSF:
>
> {code:java}
> import javax.naming.InitialContext;
> import com.mongodb.MongoClient;
> import com.mongodb.client.MongoDatabase;
> import com.mongodb.client.MongoCollection;
> import org.bson.Document;
> InitialContext cxt = new InitialContext();
> if ( cxt == null ) {
> throw new Exception("Uh oh -- no context!");
> }
> MongoClient ds = (MongoClient) cxt.lookup(
> "java:/comp/env/mongodb/MongoClient" );
> if ( ds == null ) {
> throw new Exception("Data source not found!");
> }
> MongoDatabase database = ds.getDatabase("ssp");
> //MongoCollection collection = database.getCollection("customer");
> {code}
>
> The code above runs fine, but If I uncomment the last line
> *MongoCollection collection = database.getCollection("customer")* ,
> the BSF throw a exception. See the attached *exception.txt* file.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (BSF-45) Error trying to access a MongoDB collection under Apache BSF script
[
https://issues.apache.org/jira/browse/BSF-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17049622#comment-17049622
]
Bernd Eckenfels commented on BSF-45:
I think BSF does not support generics (`<...>` you need to stick to Java 1.4
syntax.
> Error trying to access a MongoDB collection under Apache BSF script
> ---
>
> Key: BSF-45
> URL: https://issues.apache.org/jira/browse/BSF-45
> Project: Commons BSF
> Issue Type: Bug
> Components: BSF-2.x
>Affects Versions: BSF-2.4
> Environment: Java 8
> BSF 2.4.0
>Reporter: Kleyson Rios
>Priority: Major
> Attachments: exception.txt
>
>
> I'm trying to access a MongoDB collection from a java code to be 'eval' by
> BSF.
> I tried configure the MongoDB connection in both ways coding the driver
> connection and following the tutorial
> [https://mongodb.github.io/mongo-java-driver/3.10/driver/tutorials/jndi/] ,
> but in both cases the same error.
> Below the code to be executed by BSF:
>
> {code:java}
> import javax.naming.InitialContext;
> import com.mongodb.MongoClient;
> import com.mongodb.client.MongoDatabase;
> import com.mongodb.client.MongoCollection;
> import org.bson.Document;
> InitialContext cxt = new InitialContext();
> if ( cxt == null ) {
> throw new Exception("Uh oh -- no context!");
> }
> MongoClient ds = (MongoClient) cxt.lookup(
> "java:/comp/env/mongodb/MongoClient" );
> if ( ds == null ) {
> throw new Exception("Data source not found!");
> }
> MongoDatabase database = ds.getDatabase("ssp");
> //MongoCollection collection = database.getCollection("customer");
> {code}
>
> The code above runs fine, but If I uncomment the last line
> *MongoCollection collection = database.getCollection("customer")* ,
> the BSF throw a exception. See the attached *exception.txt* file.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (VFS-627) SFTP randomly hangs when copying a file on remote server
[
https://issues.apache.org/jira/browse/VFS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046874#comment-17046874
]
Bernd Eckenfels edited comment on VFS-627 at 2/27/20 6:35 PM:
--
Haven't seen another provider for VFS which does SFTP, sorry.
I am not sure if we can actually for the provider and apply your patch if the
jsch project is dormant. I think might not be possible for license reasons, but
you could fork it (or find someone who can do that, they need maven central
upload capabilities).
Do you see that with a specific kind of server software or multiple?
was (Author: b.eckenfels):
Haven't seen another provider for VFS which does SFTP, sorry. I am afraid this
requires and inspecting the protocol messages by somebody who knows the
protocol well. Do you see that with a specific kind of server software or
multiple?
> SFTP randomly hangs when copying a file on remote server
>
>
> Key: VFS-627
> URL: https://issues.apache.org/jira/browse/VFS-627
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Java 1.8.0_92
> VFS 2.1
> JSch 0.1.53
>Reporter: Henri Hagberg
>Priority: Major
>
> I have a process where a file is first copied over SFTP to local server and
> then on the remote server the file is copied to another location on that
> server for archiving. Both are done using {{FileObject#copyFrom}}. Now I've
> encountered twice the situation where during archiving (on remote server) the
> copy action hangs indefinitely (the process was left running for over 24
> hours). In both cases the issue happened when around 2000 files had been
> transferred (typical amount is under 100).
> The problem is difficult to reproduce since it doesn't always happen even
> with large number of files. Based on the stacktrace and random occurrences it
> might be a concurrency issue. The code using VFS however is single threaded.
> {code}
> Attaching to process ID 128021, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 25.92-b14
> Deadlock Detection:
> No deadlocks found.
> Thread 19073: (state = BLOCKED)
> Thread 128165: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled
> frame)
> - org.apache.commons.vfs2.cache.SoftRefFilesCache$SoftRefReleaseThread.run()
> @bci=26, line=84 (Compiled frame)
> Thread 128164: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.io.PipedInputStream.awaitSpace() @bci=23, line=273 (Compiled frame)
> - java.io.PipedInputStream.receive(byte[], int, int) @bci=31, line=231
> (Compiled frame)
> - java.io.PipedOutputStream.write(byte[], int, int) @bci=77, line=149
> (Compiled frame)
> - com.jcraft.jsch.IO.put(byte[], int, int) @bci=7, line=64 (Compiled frame)
> - com.jcraft.jsch.Channel.write(byte[], int, int) @bci=7, line=438 (Compiled
> frame)
> - com.jcraft.jsch.Session.run() @bci=1260, line=1624 (Compiled frame)
> - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> Thread 128139: (state = BLOCKED)
> Thread 128138: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled
> frame)
> - java.lang.ref.ReferenceQueue.remove() @bci=2, line=164 (Compiled frame)
> - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209
> (Interpreted frame)
> Thread 128137: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.Object.wait() @bci=2, line=502 (Compiled frame)
> - java.lang.ref.Reference.tryHandlePending(boolean) @bci=54, line=191
> (Compiled frame)
> - java.lang.ref.Reference$ReferenceHandler.run() @bci=1, line=153
> (Interpreted frame)
> Thread 128022: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - com.jcraft.jsch.Session.write(com.jcraft.jsch.Packet,
> com.jcraft.jsch.Channel, int) @bci=89, line=1261 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp.sendWRITE(byte[], long, byte[], int, int)
> @bci=191, line=2619 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp.access$100(com.jcraft.jsch.ChannelSftp,
> byte[], long, byte[], int, int) @bci=9, line=36 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp$1.write(byte[], int, int) @bci=77, line=791
> (Compiled frame)
> - java.io.BufferedOutputStream.write(byte[], int, int) @bci=20, line=122
> (Compiled frame)
> - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int)
> @bci=8, line=123 (Compiled frame)
> -
[jira] [Commented] (VFS-627) SFTP randomly hangs when copying a file on remote server
[
https://issues.apache.org/jira/browse/VFS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046874#comment-17046874
]
Bernd Eckenfels commented on VFS-627:
-
Haven't seen another provider for VFS which does SFTP, sorry. I am afraid this
requires and inspecting the protocol messages by somebody who knows the
protocol well. Do you see that with a specific kind of server software or
multiple?
> SFTP randomly hangs when copying a file on remote server
>
>
> Key: VFS-627
> URL: https://issues.apache.org/jira/browse/VFS-627
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Java 1.8.0_92
> VFS 2.1
> JSch 0.1.53
>Reporter: Henri Hagberg
>Priority: Major
>
> I have a process where a file is first copied over SFTP to local server and
> then on the remote server the file is copied to another location on that
> server for archiving. Both are done using {{FileObject#copyFrom}}. Now I've
> encountered twice the situation where during archiving (on remote server) the
> copy action hangs indefinitely (the process was left running for over 24
> hours). In both cases the issue happened when around 2000 files had been
> transferred (typical amount is under 100).
> The problem is difficult to reproduce since it doesn't always happen even
> with large number of files. Based on the stacktrace and random occurrences it
> might be a concurrency issue. The code using VFS however is single threaded.
> {code}
> Attaching to process ID 128021, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 25.92-b14
> Deadlock Detection:
> No deadlocks found.
> Thread 19073: (state = BLOCKED)
> Thread 128165: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled
> frame)
> - org.apache.commons.vfs2.cache.SoftRefFilesCache$SoftRefReleaseThread.run()
> @bci=26, line=84 (Compiled frame)
> Thread 128164: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.io.PipedInputStream.awaitSpace() @bci=23, line=273 (Compiled frame)
> - java.io.PipedInputStream.receive(byte[], int, int) @bci=31, line=231
> (Compiled frame)
> - java.io.PipedOutputStream.write(byte[], int, int) @bci=77, line=149
> (Compiled frame)
> - com.jcraft.jsch.IO.put(byte[], int, int) @bci=7, line=64 (Compiled frame)
> - com.jcraft.jsch.Channel.write(byte[], int, int) @bci=7, line=438 (Compiled
> frame)
> - com.jcraft.jsch.Session.run() @bci=1260, line=1624 (Compiled frame)
> - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> Thread 128139: (state = BLOCKED)
> Thread 128138: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled
> frame)
> - java.lang.ref.ReferenceQueue.remove() @bci=2, line=164 (Compiled frame)
> - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209
> (Interpreted frame)
> Thread 128137: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.Object.wait() @bci=2, line=502 (Compiled frame)
> - java.lang.ref.Reference.tryHandlePending(boolean) @bci=54, line=191
> (Compiled frame)
> - java.lang.ref.Reference$ReferenceHandler.run() @bci=1, line=153
> (Interpreted frame)
> Thread 128022: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - com.jcraft.jsch.Session.write(com.jcraft.jsch.Packet,
> com.jcraft.jsch.Channel, int) @bci=89, line=1261 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp.sendWRITE(byte[], long, byte[], int, int)
> @bci=191, line=2619 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp.access$100(com.jcraft.jsch.ChannelSftp,
> byte[], long, byte[], int, int) @bci=9, line=36 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp$1.write(byte[], int, int) @bci=77, line=791
> (Compiled frame)
> - java.io.BufferedOutputStream.write(byte[], int, int) @bci=20, line=122
> (Compiled frame)
> - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int)
> @bci=8, line=123 (Compiled frame)
> - java.io.BufferedOutputStream.flushBuffer() @bci=20, line=82 (Compiled
> frame)
> - java.io.BufferedOutputStream.write(byte[], int, int) @bci=39, line=126
> (Compiled frame)
> - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int)
> @bci=8, line=123 (Compiled frame)
> -
> org.apache.commons.vfs2.provider.DefaultFileContent.write(java.io.OutputStream,
> int) @bci=35, line=892 (Compiled frame)
> -
>
[jira] [Commented] (COLLECTIONS-751) Change all constructors to protected
[ https://issues.apache.org/jira/browse/COLLECTIONS-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046096#comment-17046096 ] Bernd Eckenfels commented on COLLECTIONS-751: - It is probably better you try to contribute your extensions or you inline the Apache code you need. when the classes are opened up maintaining compatibility becomes very costly. > Change all constructors to protected > > > Key: COLLECTIONS-751 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-751 > Project: Commons Collections > Issue Type: Wish >Reporter: ZHOU YANG >Priority: Minor > > Change all constructors to protected，I can inherit and extend my tools for > my projects。 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043765#comment-17043765 ] Bernd Eckenfels commented on VFS-760: - > Where are you referring to with the ownsClient? https://github.com/ottobackwards/commons-vfs/blob/zkprovider/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/zookeeper/ZkFileSystem.java#L38 I was wondering if the filesystem which owns the client has a different lifecycle from the others (i.e. you cannot close it before all others are closed). > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043696#comment-17043696 ] Bernd Eckenfels commented on VFS-760: - the jackrabit 2 module is an example for an extra provider module. But I am not sure how good it is (especially in terms of test integration) as an example. But I think improving the test-suite for modularity can be done generally. The changes for FileOrFolder looks reasonable, but I havent looked at the coverage in details. The ownsClient/framework thing - I guess this is an acceptable restriction to lifecycle. (Dont have much experience with currator, do you think it will cover all expected lifecycles?) > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (VFS-764) [webdav][tests] testing fails on java 15-ea with travis
[ https://issues.apache.org/jira/browse/VFS-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved VFS-764. - Resolution: Duplicate > [webdav][tests] testing fails on java 15-ea with travis > --- > > Key: VFS-764 > URL: https://issues.apache.org/jira/browse/VFS-764 > Project: Commons VFS > Issue Type: Bug >Reporter: Bernd Eckenfels >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-700) Some tests fail on Java 11 and above
[
https://issues.apache.org/jira/browse/VFS-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042639#comment-17042639
]
Bernd Eckenfels commented on VFS-700:
-
This does not fail anymore, not sure if by accident or intentional, the system
property is set.
i will leave that open till the certificate ismchecked/renewed and the property
is therefore removed.
> Some tests fail on Java 11 and above
>
>
> Key: VFS-700
> URL: https://issues.apache.org/jira/browse/VFS-700
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Gary D. Gregory
>Priority: Major
>
> Some tests fail on Java 11 and above: https://travis-ci.org/apache/commons-vfs
> {noformat}
> Tests in error:
>
> AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166
> » FileSystem
>
> AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166
> » FileSystem
> MultipleConnectionTestCase.testConnectRoot:55->resolveRoot:49 » FileSystem
> Cou...
> MultipleConnectionTestCase.testUnderlyingConnect:65 » SSL Unsupported or
> unrec...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (VFS-765) [webdav][tests] jackrabit1 module webdav tests fail with IllegalStateException on java 15-ea
Bernd Eckenfels created VFS-765:
---
Summary: [webdav][tests] jackrabit1 module webdav tests fail with
IllegalStateException on java 15-ea
Key: VFS-765
URL: https://issues.apache.org/jira/browse/VFS-765
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.6.0
Reporter: Bernd Eckenfels
The tests of the kackrabit1 module fail on Travis-CI when using java 15-ea
builds:
{{Running org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase}}
{{ 4826SLF4J: Class path contains multiple SLF4J bindings.}}
{{ 4827SLF4J: Found binding in
[jar:file:/home/travis/.m2/repository/org/slf4j/slf4j-log4j12/1.5.11/slf4j-log4j12-1.5.11.jar!/org/slf4j/impl/StaticLoggerBinder.class]}}
{{ 4828SLF4J: Found binding in
[jar:file:/home/travis/.m2/repository/org/apache/jackrabbit/jackrabbit-standalone/1.6.5/jackrabbit-standalone-1.6.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]}}
{{ 4829SLF4J: See [http://www.slf4j.org/codes.html#multiple_bindings] for an
explanation.}}
{{ 4830Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.282
sec <<< FAILURE! - in
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase}}
{{
4831junit.framework.TestSuite@5c73f672(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1)
Time elapsed: 4.282 sec <<< ERROR!}}
{{ 4832java.lang.IllegalStateException: Not initialized}}
{{ 4833 at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1.setUp(WebdavProviderTestCase.java:244)}}
{{This is fixed by https://github.com/apache/commons-vfs/pull/87}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (VFS-764) [webdav][tests] testing fails on java 15-ea with travis
Bernd Eckenfels created VFS-764: --- Summary: [webdav][tests] testing fails on java 15-ea with travis Key: VFS-764 URL: https://issues.apache.org/jira/browse/VFS-764 Project: Commons VFS Issue Type: Bug Reporter: Bernd Eckenfels -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042184#comment-17042184 ] Bernd Eckenfels commented on VFS-760: - Maybe the tests can be made conditional based on some capabilities? Will have a look at it, but generally I would merge it rather sooner then later (and not adding the module in default maven profile till it's sorted out) > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VFS-762) Replace Configuration XML With Annotations on Providers
[ https://issues.apache.org/jira/browse/VFS-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-762: Issue Type: Wish (was: New Feature) Priority: Minor (was: Major) > Replace Configuration XML With Annotations on Providers > --- > > Key: VFS-762 > URL: https://issues.apache.org/jira/browse/VFS-762 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-761) Dynamically Load File Systems From Classpath
[ https://issues.apache.org/jira/browse/VFS-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041324#comment-17041324 ] Bernd Eckenfels commented on VFS-761: - We do that for new provides if they have specific dependencies, but I don't think it's worth the effort for the existing providers. You normally don't interact with the provided directly, and if you use a custom FileSystemManager you can decide for yourself which schemes are loaded. It is also no problem to not provide dependencies for the providers you don't need (you could even skip the packages when you want to minimize the footprint, but those few bytes saved are certainly not worth the maintenance overhead. If anybody wants to do that I strongly recommend to discuss it on commons-dev first. I veto all changes which just duplicates the test suite (as it currently is not good for that modularisation). > Dynamically Load File Systems From Classpath > > > Key: VFS-761 > URL: https://issues.apache.org/jira/browse/VFS-761 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > I would like to see each File System separated into its own project. > To setup my project, I would like to import a single VFS Binder project which > will then load all File Systems that are included on the class path. > Thereby, I can include only the File Systems I want by including them in the > Maven POM as dependencies and not have to include the code for every single > File System. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VFS-761) Dynamically Load File Systems From Classpath
[ https://issues.apache.org/jira/browse/VFS-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-761: Priority: Minor (was: Major) > Dynamically Load File Systems From Classpath > > > Key: VFS-761 > URL: https://issues.apache.org/jira/browse/VFS-761 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > I would like to see each File System separated into its own project. > To setup my project, I would like to import a single VFS Binder project which > will then load all File Systems that are included on the class path. > Thereby, I can include only the File Systems I want by including them in the > Maven POM as dependencies and not have to include the code for every single > File System. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VFS-761) Dynamically Load File Systems From Classpath
[ https://issues.apache.org/jira/browse/VFS-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-761: Issue Type: Wish (was: New Feature) > Dynamically Load File Systems From Classpath > > > Key: VFS-761 > URL: https://issues.apache.org/jira/browse/VFS-761 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Major > > I would like to see each File System separated into its own project. > To setup my project, I would like to import a single VFS Binder project which > will then load all File Systems that are included on the class path. > Thereby, I can include only the File Systems I want by including them in the > Maven POM as dependencies and not have to include the code for every single > File System. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-760: Priority: Minor (was: Critical) > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-760: Priority: Blocker (was: Major) > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Blocker > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-760: Priority: Critical (was: Blocker) > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Critical > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-760: Issue Type: Wish (was: New Feature) > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Major > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved VFS-180. - Fix Version/s: 2.5.0 Resolution: Fixed webdav4s: is provided in commons-vfs2-jackrabbit2:2.5.0 ff > Support HTTPS / SSL for Webdav > -- > > Key: VFS-180 > URL: https://issues.apache.org/jira/browse/VFS-180 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.0, 2.0 >Reporter: Werner Mueller >Priority: Major > Labels: patch > Fix For: 2.5.0 > > Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, > patch_180_vfs2.txt, patch_180_vfs2.txt > > Time Spent: 10m > Remaining Estimate: 0h > > The Slide Webdav lib supports encrypted HTTPS connections. So it should be > possible to add https support to vfs too. currently the webdav provider > creates http urls (in WebdavClientFactory.java). > maybe some provider like 'webdavs' could be added to switch to HttpsUrl. > regards > werner -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040267#comment-17040267 ] Bernd Eckenfels edited comment on VFS-180 at 2/19/20 5:48 PM: -- [~szkxv6] could you be a bit more specific? What does not work? You say turns back into - does that mean one request is https and the other is not? Which vfs version are you trying and what http client and jackrabbit client version is on the classpath? Maybe you have a sample code which fails... any specific operation? BTW: I am not sure why we don't deliver a webdavs method, is that related to the old package not having support for it? Anyway, this bug looks resolved to me since 2.5 which introduced the extra provider modules. was (Author: b.eckenfels): [~szkxv6] could you be a bit more specific? What does not work? You say turns back into - does that mean one request is https and the other is not? Which vfs version are you trying and what http client version is on the classpath? Maybe you have a sample code which fails... any specific operation? > Support HTTPS / SSL for Webdav > -- > > Key: VFS-180 > URL: https://issues.apache.org/jira/browse/VFS-180 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.0, 2.0 >Reporter: Werner Mueller >Priority: Major > Labels: patch > Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, > patch_180_vfs2.txt, patch_180_vfs2.txt > > Time Spent: 10m > Remaining Estimate: 0h > > The Slide Webdav lib supports encrypted HTTPS connections. So it should be > possible to add https support to vfs too. currently the webdav provider > creates http urls (in WebdavClientFactory.java). > maybe some provider like 'webdavs' could be added to switch to HttpsUrl. > regards > werner -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040267#comment-17040267 ] Bernd Eckenfels commented on VFS-180: - [~szkxv6] could you be a bit more specific? What does not work? You say turns back into - does that mean one request is https and the other is not? Which vfs version are you trying and what http client version is on the classpath? Maybe you have a sample code which fails... any specific operation? > Support HTTPS / SSL for Webdav > -- > > Key: VFS-180 > URL: https://issues.apache.org/jira/browse/VFS-180 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.0, 2.0 >Reporter: Werner Mueller >Priority: Major > Labels: patch > Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, > patch_180_vfs2.txt, patch_180_vfs2.txt > > Time Spent: 10m > Remaining Estimate: 0h > > The Slide Webdav lib supports encrypted HTTPS connections. So it should be > possible to add https support to vfs too. currently the webdav provider > creates http urls (in WebdavClientFactory.java). > maybe some provider like 'webdavs' could be added to switch to HttpsUrl. > regards > werner -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-752) AbstractFileProvider close should close all fileSystems before clearing the cache
[ https://issues.apache.org/jira/browse/VFS-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010810#comment-17010810 ] Bernd Eckenfels commented on VFS-752: - (And i think the File Provider does close all of it's components, which is the file system, so maybe the problem is more in the (missing) close method of file systems?) > AbstractFileProvider close should close all fileSystems before clearing the > cache > - > > Key: VFS-752 > URL: https://issues.apache.org/jira/browse/VFS-752 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Harald Kuhn >Priority: Major > > The close method of AbstractFileProvider currently only clears the cache of > FileSystem references without closing them first. This can cause open > connections (e.g. with the SFTPProvider) if each FileSystem is not > explicitly closed via closeFileSystem. This is a bit error prone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-752) AbstractFileProvider close should close all fileSystems before clearing the cache
[ https://issues.apache.org/jira/browse/VFS-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010803#comment-17010803 ] Bernd Eckenfels commented on VFS-752: - We might also need a different close method on FileObject, because the current one only closes the thread local part of file content and then forgets the filecontent so it can never be closed for the other threads. But I think this severity can be scaled down, it should be unlikely that the provider instead of the Filesystem is closed (because that would have a lot of splash damage in multithreaded apps). > AbstractFileProvider close should close all fileSystems before clearing the > cache > - > > Key: VFS-752 > URL: https://issues.apache.org/jira/browse/VFS-752 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Harald Kuhn >Priority: Major > > The close method of AbstractFileProvider currently only clears the cache of > FileSystem references without closing them first. This can cause open > connections (e.g. with the SFTPProvider) if each FileSystem is not > explicitly closed via closeFileSystem. This is a bit error prone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-627) SFTP randomly hangs when copying a file on remote server
[
https://issues.apache.org/jira/browse/VFS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989694#comment-16989694
]
Bernd Eckenfels commented on VFS-627:
-
Thanks james for debugging this. I guess we keep this bug around till we JSch
has fixed it and we upgraded to that version.
> SFTP randomly hangs when copying a file on remote server
>
>
> Key: VFS-627
> URL: https://issues.apache.org/jira/browse/VFS-627
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Java 1.8.0_92
> VFS 2.1
> JSch 0.1.53
>Reporter: Henri Hagberg
>Priority: Major
>
> I have a process where a file is first copied over SFTP to local server and
> then on the remote server the file is copied to another location on that
> server for archiving. Both are done using {{FileObject#copyFrom}}. Now I've
> encountered twice the situation where during archiving (on remote server) the
> copy action hangs indefinitely (the process was left running for over 24
> hours). In both cases the issue happened when around 2000 files had been
> transferred (typical amount is under 100).
> The problem is difficult to reproduce since it doesn't always happen even
> with large number of files. Based on the stacktrace and random occurrences it
> might be a concurrency issue. The code using VFS however is single threaded.
> {code}
> Attaching to process ID 128021, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 25.92-b14
> Deadlock Detection:
> No deadlocks found.
> Thread 19073: (state = BLOCKED)
> Thread 128165: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled
> frame)
> - org.apache.commons.vfs2.cache.SoftRefFilesCache$SoftRefReleaseThread.run()
> @bci=26, line=84 (Compiled frame)
> Thread 128164: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.io.PipedInputStream.awaitSpace() @bci=23, line=273 (Compiled frame)
> - java.io.PipedInputStream.receive(byte[], int, int) @bci=31, line=231
> (Compiled frame)
> - java.io.PipedOutputStream.write(byte[], int, int) @bci=77, line=149
> (Compiled frame)
> - com.jcraft.jsch.IO.put(byte[], int, int) @bci=7, line=64 (Compiled frame)
> - com.jcraft.jsch.Channel.write(byte[], int, int) @bci=7, line=438 (Compiled
> frame)
> - com.jcraft.jsch.Session.run() @bci=1260, line=1624 (Compiled frame)
> - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> Thread 128139: (state = BLOCKED)
> Thread 128138: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled
> frame)
> - java.lang.ref.ReferenceQueue.remove() @bci=2, line=164 (Compiled frame)
> - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209
> (Interpreted frame)
> Thread 128137: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.Object.wait() @bci=2, line=502 (Compiled frame)
> - java.lang.ref.Reference.tryHandlePending(boolean) @bci=54, line=191
> (Compiled frame)
> - java.lang.ref.Reference$ReferenceHandler.run() @bci=1, line=153
> (Interpreted frame)
> Thread 128022: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - com.jcraft.jsch.Session.write(com.jcraft.jsch.Packet,
> com.jcraft.jsch.Channel, int) @bci=89, line=1261 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp.sendWRITE(byte[], long, byte[], int, int)
> @bci=191, line=2619 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp.access$100(com.jcraft.jsch.ChannelSftp,
> byte[], long, byte[], int, int) @bci=9, line=36 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp$1.write(byte[], int, int) @bci=77, line=791
> (Compiled frame)
> - java.io.BufferedOutputStream.write(byte[], int, int) @bci=20, line=122
> (Compiled frame)
> - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int)
> @bci=8, line=123 (Compiled frame)
> - java.io.BufferedOutputStream.flushBuffer() @bci=20, line=82 (Compiled
> frame)
> - java.io.BufferedOutputStream.write(byte[], int, int) @bci=39, line=126
> (Compiled frame)
> - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int)
> @bci=8, line=123 (Compiled frame)
> -
> org.apache.commons.vfs2.provider.DefaultFileContent.write(java.io.OutputStream,
> int) @bci=35, line=892 (Compiled frame)
> -
> org.apache.commons.vfs2.provider.DefaultFileContent.write(java.io.OutputStream)
> @bci=5, line=865 (Compiled frame)
> -
>
[jira] [Commented] (VFS-617) isReadable fails if unable to determine group identity
[ https://issues.apache.org/jira/browse/VFS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975857#comment-16975857 ] Bernd Eckenfels commented on VFS-617: - Vineet, I would assume the simplest way to avoid this problem is to not use the isReadable method in this context. I don’t see in the stacktrace who is actually calling it, but if it is your code, just don’t do it. > isReadable fails if unable to determine group identity > -- > > Key: VFS-617 > URL: https://issues.apache.org/jira/browse/VFS-617 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows 7 Java 7. Failure occured connecting via SFTP to > a Synology box running DSM 6. >Reporter: Tim Nickels >Priority: Major > > The doIsReadable method of SftpFileObject throws an exception if the system > cannot identify group/owner permissions... > Exception in thread "main" org.apache.commons.vfs2.FileSystemException: Could > not determine if file "sftp://myURI; is readable. > at > org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1761) > at com.avenca.vfs.VFSUtils.main(VFSUtils.java:41) > Caused by: com.jcraft.jsch.JSchException: Could not get the groups id of the > current user (error code: 1) > at > org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getGroupsIds(SftpFileSystem.java:263) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.getPermissions(SftpFileObject.java:317) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.doIsReadable(SftpFileObject.java:335) > at > org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1757) > The problem is the method is using > return getPermissions(true).isReadable() > The folder *is* readable without these permissions, and so should be set to > return getPermissions(false).isReadable() > Which correctly allows the system to identify a readable folder without > adding unnecessary restrictions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (VFS-745) GetOrCreateFilesystemCaches might return unused Map
Bernd Eckenfels created VFS-745: --- Summary: GetOrCreateFilesystemCaches might return unused Map Key: VFS-745 URL: https://issues.apache.org/jira/browse/VFS-745 Project: Commons VFS Issue Type: Bug Affects Versions: 2.4.1 Reporter: Bernd Eckenfels The LRauFilesCache implementations contains a `getOrCreateFilesystemCache` which uses putIfAbsent, however the returned cache might not be the one (not) put into the filesystemCaches map. https://github.com/apache/commons-vfs/blob/b6fb9a392d9510ce039e55a26a47ed85750a4386/commons-vfs2/src/main/java/org/apache/commons/vfs2/cache/LRUFilesCache.java#L192 Also this should be probably inside the write lock, and the getFile should have the optimization not to create a filesystem entry like DefaultFilesCache does. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (VFS-741) Listing files with known prefix still fails
[ https://issues.apache.org/jira/browse/VFS-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved VFS-741. - Fix Version/s: 2.5.0 Assignee: Bernd Eckenfels Resolution: Fixed Fixed on master https://gitbox.apache.org/repos/asf?p=commons-vfs.git;a=commit;h=d79524d567f4bbd9e9b8e056451ede70e89abd35 > Listing files with known prefix still fails > --- > > Key: VFS-741 > URL: https://issues.apache.org/jira/browse/VFS-741 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.4.1 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Major > Fix For: 2.5.0 > > > Efen after VFS-298 the listing of files in a directory may fail with > "FileSystemException: Invalid descendent file name" if the filename contains > a known/registered scheme. > A trivial fix is in AFO to simply resolve the children names with a ./ > prefix, which makes them parse without a scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (VFS-741) Listing files with known prefix still fails
Bernd Eckenfels created VFS-741: --- Summary: Listing files with known prefix still fails Key: VFS-741 URL: https://issues.apache.org/jira/browse/VFS-741 Project: Commons VFS Issue Type: Bug Affects Versions: 2.4.1 Reporter: Bernd Eckenfels Efen after VFS-298 the listing of files in a directory may fail with "FileSystemException: Invalid descendent file name" if the filename contains a known/registered scheme. A trivial fix is in AFO to simply resolve the children names with a ./ prefix, which makes them parse without a scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RNG-88) Update the GenerationPerformance benchmark
[ https://issues.apache.org/jira/browse/RNG-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809710#comment-16809710 ] Bernd Eckenfels commented on RNG-88: Just a BTW The JMH harness goes to great length in removing artifacts from the actual measurements. You can add a baseline method here however I would avoid trying to massage the returned results in any way. For relative comparison it’s not needed anyway (and overhead should also be observable by varrying request length if possible) > Update the GenerationPerformance benchmark > -- > > Key: RNG-88 > URL: https://issues.apache.org/jira/browse/RNG-88 > Project: Commons RNG > Issue Type: Improvement > Components: examples >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Attachments: baseline.jpg, next.png > > > The current GenerationPerformance benchmark runs all the generators to > collect timing data. However the act of running the test within JMH takes > some time (test overhead). This overhead should be measured and subtracted > from the timing data to create a time attributed only to the method exercised > in the RNG. > This can be done by creating a dummy RNG that returns a fixed value. The > implementation must be done in a manner where the JIT compiler is not able to > remove the dummy method from the execution path. This is achieved by > returning state variables from the dummy RNG (not final variables). > Testing can be done using a variable number of iterations and the run-times > assessed for linearity. If the run time scale with the number of iterations > then the JIT compiler has not removed it from execution. The dummy RNG then > serves as a baseline for comparison of true implementations. > This idea with examples is shown in > [RNG-87|https://issues.apache.org/jira/browse/RNG-87] which tested a variant > of the MWC_256 algorithm. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NET-668) Commons net 3.5 and 3.6 have different implementation for uploading files over TFTP
[ https://issues.apache.org/jira/browse/NET-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800517#comment-16800517 ] Bernd Eckenfels commented on NET-668: - In order for someone to fix the bug we should know what is broken. Do you maybe have traces you can compare? > Commons net 3.5 and 3.6 have different implementation for uploading files > over TFTP > --- > > Key: NET-668 > URL: https://issues.apache.org/jira/browse/NET-668 > Project: Commons Net > Issue Type: Wish > Components: TFTP >Affects Versions: 3.5, 3.6 >Reporter: Ivan Puntev >Priority: Major > > I upload firmware to a device over TFTP and I use apache-commons-net 3.5. > Everything works fine with this version. > I saw that in 3.6 there is a upload progress added and I decided to update > the library and add progress bar on the tool that I use but then the > functionality broke. I checked and found that the implementation of the > sendFile() method has changed. > Can someone tell me what needs to be done in this situation? I need upload > progress. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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=16746342#comment-16746342
]
Bernd Eckenfels commented on VFS-398:
-
I think the overall idea of checking for known schemes is an option to solve
this dilemma (unclear when URI and when file names are used), but I am not sure
about the implementation details: the change seems to use getScheme() very
often and this method constructs a new response object every time, that might
be performance critical (I havent measured it yet, but in the past I say a lot
of resolves in normal operations).
Also changing the sequence of cleanup when closing the manager was very tricky
in the past, so hopefully providers.clear() is ok in the new patch.
> 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
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> 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
(v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722825#comment-16722825
]
Bernd Eckenfels commented on FILEUPLOAD-279:
Snapshots are not released and therefore always "use at own risk", if you know
the commit the snapshot is based upon you can check thesource yourself.
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file
> from disk.
> That filename is always generated via getOutputStream.
>
[jira] [Commented] (VFS-685) Test classes should be public so test suits can be extended
[ https://issues.apache.org/jira/browse/VFS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713202#comment-16713202 ] Bernd Eckenfels commented on VFS-685: - Just a FYI, I have an provider which runs the whole provider testsuite from the main project by ways of depending on the test jar. However it has some problems with resources and the `code.*` classes. And the logic is really really hard to understand at all. [https://github.com/ecki/seeburger-vfs2/blob/master/vfs2provider-jdbctable/src/test/java/com/seeburger/vfs2/provider/jdbctable/test/H2ProviderTestCase.java] > Test classes should be public so test suits can be extended > --- > > Key: VFS-685 > URL: https://issues.apache.org/jira/browse/VFS-685 > Project: Commons VFS > Issue Type: Bug >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > > FileInfo and possibly other classes should be public, that way someone can > write tests for their providers that extend and are close to the same as the > project tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711420#comment-16711420
]
Bernd Eckenfels commented on FILEUPLOAD-279:
ASF bylaws makes it hard to offer snapshots and I would agree that we should
not do it. (if there is a good reason for users to request 1.4 snapshots it
might be time for a release?). Should we discuss this on the users or dev
mailing list?
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to
[jira] [Comment Edited] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711401#comment-16711401
]
Bernd Eckenfels edited comment on FILEUPLOAD-279 at 12/6/18 12:52 PM:
--
[~joc...@apache.org] I dont think thats entirely correct, I dont see the
orifginal system-property changes in the master file and the changes.xml is
messed up. Is the 1.4 branch supposed to have a "different" solution than
_this_ 1.3.3 fix?
was (Author: b.eckenfels):
[~joc...@apache.org] I dont think thats correct, I dont see the changes in the
master file and the changes.xml is messed up. The master branch looks borken to
me.
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711401#comment-16711401
]
Bernd Eckenfels commented on FILEUPLOAD-279:
[~joc...@apache.org] I dont think thats correct, I dont see the changes in the
master file and the changes.xml is messed up. The master branch looks borken to
me.
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file
> from disk.
> That filename is always generated via
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711376#comment-16711376
]
Bernd Eckenfels commented on FILEUPLOAD-279:
[~rasmita] it looks like the fix is missing in master/b1_4.
(There are other problems with the master, like a broken changes.xml). I would
think sticking with 1.3.3 is better until a official 1.4 release.)
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file
> from disk.
> That
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695202#comment-16695202
]
Bernd Eckenfels commented on VFS-683:
-
Just FYI, I had similiar problems. In my case I made sure that the overlay
filesystem I was using had a different filesystem instance, so it was not
closing for other threads. But there are definitly a few concurrency problems
(and if there are not concurrency problems then there are
cleanup/excessive-clone problems). Let me see if I can find the details of my
research in that area.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684646#comment-16684646
]
Bernd Eckenfels edited comment on FILEUPLOAD-279 at 11/13/18 2:49 AM:
--
This is not (directly) related to Struts.
The DiskFileItem class lingers around in your applications and this adds a
trivial Widget to be exploited by serialisation attacks. It might not be the
only vector, and deserialising untrusted data is fatal in itself, hoewever you
would still be guilty of not having updated a class with known vulnerabilities.
So just update.
if you cant update (for whatever reason) then the only thing to mitigate you
can do is to actually review all usage of serialisation in your apps. You
should probably do that anyway.
it might be possible that you notice upload_uuid_id.tmp file in random
directories, but they do only show up for short times if it is used to generate
files.
I would lIke like to better understand why can’t people just upgrade, is there
something we can make it easier?
was (Author: b.eckenfels):
This is not (directly) related to Struts.
The DiskFileItem class lingers around in your applications and this adds a
trivial Widget to be exploited by serialisation attacks. It might not be the
only vector, and deserialising untrusted data is fatal in itself, hoewever you
would still be guilty of not having updated a class with known vulnerabilities.
So just update.
if you cant update (for whatever reason) then the only thing to mitigate you
can do is to actually review all usage of serialisation in your apps. You
should probably do that anyway.
it might be possible that you notice upload_uuid_id.tmp file in random
directories, but they do only show up for short times if it is used to generate
files.
I would better like to understand why can’t people just upgrade, is there
something we can make it easier?
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684646#comment-16684646
]
Bernd Eckenfels commented on FILEUPLOAD-279:
This is not (directly) related to Struts.
The DiskFileItem class lingers around in your applications and this adds a
trivial Widget to be exploited by serialisation attacks. It might not be the
only vector, and deserialising untrusted data is fatal in itself, hoewever you
would still be guilty of not having updated a class with known vulnerabilities.
So just update.
if you cant update (for whatever reason) then the only thing to mitigate you
can do is to actually review all usage of serialisation in your apps. You
should probably do that anyway.
it might be possible that you notice upload_uuid_id.tmp file in random
directories, but they do only show up for short times if it is used to generate
files.
I would better like to understand why can’t people just upgrade, is there
something we can make it easier?
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677377#comment-16677377
]
Bernd Eckenfels commented on FILEUPLOAD-279:
The „safe“ thing to do is, if you are in doubt then assume you need to upgrade
to not be vulnerable. (And it reduces the amount of justification and
explaining you have to do when you are regularly bombarded with scan reports
and requests for asking for exceptions to keep old, known vulnerable versions
around)
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization
[jira] [Resolved] (VFS-678) LGTM (automatic code review) issues
[ https://issues.apache.org/jira/browse/VFS-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved VFS-678. - Resolution: Fixed Ok, no LGTM alerts left. > LGTM (automatic code review) issues > --- > > Key: VFS-678 > URL: https://issues.apache.org/jira/browse/VFS-678 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Minor > Fix For: 2.2.1 > > > The LGTM.com code review system has some issues with VFS2 code: > https://lgtm.com/projects/g/apache/commons-vfs/alerts/?mode=list > Namely: > DefaultCryptor.java: 111,114 - index might be equal to array length > MonitorInputStream.java: 60, 86 - method overwrites a synchronized method > UserAuthenticationData.java: 132 - test always false > Shell.java: 157 - array to string > DefaultFileMonitor.java: 493: - may be null > ShowFileTask.java: 126 - resource leak > FileName.java: 144 - javadoc > CompressedFileFileProvider.java: 42 - javadoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-678) LGTM (automatic code review) issues
[ https://issues.apache.org/jira/browse/VFS-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-678: Fix Version/s: 2.2.1 > LGTM (automatic code review) issues > --- > > Key: VFS-678 > URL: https://issues.apache.org/jira/browse/VFS-678 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Minor > Fix For: 2.2.1 > > > The LGTM.com code review system has some issues with VFS2 code: > https://lgtm.com/projects/g/apache/commons-vfs/alerts/?mode=list > Namely: > DefaultCryptor.java: 111,114 - index might be equal to array length > MonitorInputStream.java: 60, 86 - method overwrites a synchronized method > UserAuthenticationData.java: 132 - test always false > Shell.java: 157 - array to string > DefaultFileMonitor.java: 493: - may be null > ShowFileTask.java: 126 - resource leak > FileName.java: 144 - javadoc > CompressedFileFileProvider.java: 42 - javadoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-678) LGTM (automatic code review) issues
[ https://issues.apache.org/jira/browse/VFS-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672360#comment-16672360 ] Bernd Eckenfels commented on VFS-678: - Hopefully fixed with [http://svn.apache.org/viewvc?rev=1845521=rev] (amended by [http://svn.apache.org/viewvc?rev=1845523=rev).] Waiting for git-mirror and LGTM.com to catch up before I close this. > LGTM (automatic code review) issues > --- > > Key: VFS-678 > URL: https://issues.apache.org/jira/browse/VFS-678 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Minor > Fix For: 2.2.1 > > > The LGTM.com code review system has some issues with VFS2 code: > https://lgtm.com/projects/g/apache/commons-vfs/alerts/?mode=list > Namely: > DefaultCryptor.java: 111,114 - index might be equal to array length > MonitorInputStream.java: 60, 86 - method overwrites a synchronized method > UserAuthenticationData.java: 132 - test always false > Shell.java: 157 - array to string > DefaultFileMonitor.java: 493: - may be null > ShowFileTask.java: 126 - resource leak > FileName.java: 144 - javadoc > CompressedFileFileProvider.java: 42 - javadoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-678) LGTM (automatic code review) issues
Bernd Eckenfels created VFS-678: --- Summary: LGTM (automatic code review) issues Key: VFS-678 URL: https://issues.apache.org/jira/browse/VFS-678 Project: Commons VFS Issue Type: Bug Affects Versions: 2.2 Reporter: Bernd Eckenfels Assignee: Bernd Eckenfels The LGTM.com code review system has some issues with VFS2 code: https://lgtm.com/projects/g/apache/commons-vfs/alerts/?mode=list Namely: DefaultCryptor.java: 111,114 - index might be equal to array length MonitorInputStream.java: 60, 86 - method overwrites a synchronized method UserAuthenticationData.java: 132 - test always false Shell.java: 157 - array to string DefaultFileMonitor.java: 493: - may be null ShowFileTask.java: 126 - resource leak FileName.java: 144 - javadoc CompressedFileFileProvider.java: 42 - javadoc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DBCP-461) Prepared statements are not cached with XA
[
https://issues.apache.org/jira/browse/DBCP-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16556816#comment-16556816
]
Bernd Eckenfels commented on DBCP-461:
--
Are you sure you reported this in the right project? Seems to me like a problem
in the interceptor from the Tomcat project. The DBCP uses
`poolPreparedStatements=true` instead.
> Prepared statements are not cached with XA
> --
>
> Key: DBCP-461
> URL: https://issues.apache.org/jira/browse/DBCP-461
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: TomEE Version : Apache Tomcat Version 7.0.63
>Reporter: Sailaja
>Priority: Major
>
> Prepared statements are not getting cached when I use XA datasource.
> Please find the below program :
> {code:java}
> public static void main(String[] args) throws Exception {
> final TransactionManager transactionManager =
> TransactionManagerFactory.getTransactionManager();
> final PoolProperties poolProperties = new PoolProperties();
> SQLServerDataSource dataSource = new
> com.microsoft.sqlserver.jdbc.SQLServerDataSource();
> dataSource.setUser("sa");
> dataSource.setPassword("$9Lserver");
>
> dataSource.setURL("jdbc:sqlserver://sdwivedi63ks022:1433;sendStringParametersAsUnicode=false");
> dataSource.setDatabaseName("himalaya");
> poolProperties.setDataSource(dataSource);
> final String jdbcInterceptors =
> "org.apache.tomcat.jdbc.pool.interceptor.StatementCache(prepared=true,callable=true)";
> poolProperties.setJdbcInterceptors(jdbcInterceptors);
> final org.apache.tomcat.jdbc.pool.DataSource pooledOracleDatasource =
> new org.apache.tomcat.jdbc.pool.XADataSource(poolProperties);
> final javax.sql.DataSource oracleDataSource = new
> org.apache.openejb.resource.jdbc.managed.xa.ManagedXADataSource(pooledOracleDatasource,
> transactionManager,
> TransactionProvider.getTransactionSynchronizationRegistry());
> Connection connection = oracleDataSource.getConnection();
> for (int i = 0; i < 50; i++) {
> PreparedStatement preparedStatement =
> connection.prepareStatement("insert into MyTableNew values (" + i + ")");
> System.out.println(preparedStatement.getClass().getName());
> preparedStatement.execute();
> preparedStatement.close();
> }
> connection.close();
> }
> {code}
> If I run the above program, the output I see is:
> com.sun.proxy.$Proxy11
> If I just change the above program to use XA datasource, i.e.
> Change the following line
> SQLServerDataSource dataSource = new
> com.microsoft.sqlserver.jdbc.SQLServerDataSource();
> To
> SQLServerXADataSource dataSource = new
> com.microsoft.sqlserver.jdbc.SQLServerXADataSource();
> The output is :
> com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443380#comment-16443380 ] Bernd Eckenfels commented on VFS-661: - It hink it is a good idea to add FileObject#resolveCanonical() returning the canonical FileName. For local files this would map to File#getCanonicalPath() However I am not sure if the Cifs API does Support that anyway. But for your usecase you could either use a case insensitive comparator or store the URL in lowercase. FileName resolveCanonical() instead of getCanonicalFile to make it clear it’s a slow IO intensive method (not the missleading getter from java.io) > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-498) OSGI MANIFEST.MF "Import-Package" should be ";resolution:=optional" for Maven "optional" dependencies
[
https://issues.apache.org/jira/browse/VFS-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384848#comment-16384848
]
Bernd Eckenfels commented on VFS-498:
-
You can open a new bug, its easier to track that way.
> OSGI MANIFEST.MF "Import-Package" should be ";resolution:=optional" for Maven
> "optional" dependencies
> -
>
> Key: VFS-498
> URL: https://issues.apache.org/jira/browse/VFS-498
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Michael Schnell
>Assignee: Bernd Eckenfels
>Priority: Major
> Fix For: 2.1
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> In the Maven "pom.xml" there are several "optional" dependencies like "jsch":
> {quote}
>
> com.jcraft
> jsch
> true
>
> {quote}
> In the "Import-Package" section of the MANIFEST.MF it should also be
> "optional" like this:
> {quote}
> com.jcraft.jsch;resolution:=optional,
> {quote}
> At the moment all dependencies are always required. This is a problem if you
> want to use VFS in an OSGI environment as you have to install ALL
> dependencies and not only the ones you really need.
> The mechanism creating the MANIFEST should be adjusted to reflect the
> optional dependencies also in the MANIFEST. (Unfortunatelly this could mean
> to list all packages which should be optional).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
