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

Reply via email to