You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Andrew Gaul (JIRA)" <ji...@apache.org> on 2018/06/07 05:53:00 UTC
[jira] [Resolved] (JCLOUDS-1422) LocalBlobStore.list ignores
recursive flag when prefix set
[ https://issues.apache.org/jira/browse/JCLOUDS-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Gaul resolved JCLOUDS-1422.
----------------------------------
Resolution: Fixed
Assignee: Andrew Gaul
Fix Version/s: 2.1.1
2.2.0
> LocalBlobStore.list ignores recursive flag when prefix set
> ----------------------------------------------------------
>
> Key: JCLOUDS-1422
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1422
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
> Affects Versions: 2.0.0, 2.2.0
> Reporter: Jesse Glick
> Assignee: Andrew Gaul
> Priority: Major
> Labels: filesystem, transient
> Fix For: 2.2.0, 2.1.1
>
>
> While [calling jclouds code to list a container|https://github.com/jenkinsci/artifact-manager-s3-plugin/blob/2f30460a8be33f9abdde80f91ed1edd9977e5d61/src/main/java/io/jenkins/plugins/artifact_manager_s3/JCloudsVirtualFile.java#L187-L191] I noticed that while the S3 implementation can handle both {{prefix}} and {{recursive}} on or off, when using the {{transient}} implementation the {{recursive}} flag seems to be ignored—the code always behaves as if it were on. I looked into {{LocalBlobStore.list}} and saw that indeed since JCLOUDS-930 the implementation just [checks {{prefix}} before {{recursive}}|https://github.com/jclouds/jclouds/blob/b76a594e816b0c04a8382b1876e160ae4581ae09/blobstore/src/main/java/org/jclouds/blobstore/config/LocalBlobStore.java#L272-L277] and in that case calls {{filterPrefix}} which ignores {{recursive}} without calling {{extractCommonPrefixes}} like all other code branchs called when {{!recursive}}. It was tricky to see what exactly the desired behavior was (especially when the {{prefix}} does not end with the separator/delimiter), since the Javadoc of {{ListContainerOptions}} is sparse and vague, but I reasoned that the current behavior was wrong since
> * the S3 implementation behaves differently
> * the current implementation quietly fails to differentiate two option combinations, with no code in {{ListContainerOptions}} indicating that one implies the other
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)