[jira] [Updated] (JCLOUDS-1422) LocalBlobStore.list ignores recursive flag when prefix set

["Andrew Gaul (JIRA)" <ji...@apache.org>]

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

Andrew Gaul updated JCLOUDS-1422:
---------------------------------
    Labels: filesystem transient  (was: )

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