@dkocher commented

is it possible to get a temporary account on the server to debug the issue?

@dkocher commented

Similar unresolved issue for Cloudfiles in #5350.

@dkocher commented

For the particular container I get the following response

<?xml version="1.0" encoding="UTF-8"?>
<container name="myfiles"></container>

for the request to

/v1/AUTH_385b0d5e6ef544379f22bd38099c9f32/myfiles?format=xml&path=

with the following headers

X-Auth-Token: AUTH_tk2f0e65b3e530439a9e77a1779710a2f4
User-Agent: Cyberduck/4.0b7 (7726:7728MP) (Mac OS X/10.6.5) (i386)
Host: storage.cloud.bvox.net

Have to compare with st client. Do you know how to make st more verbose printing the headers etc.?

@dkocher commented

The compatibility issue seems to be that we always send a path query argument with an empty value.

e09940a commented

st do not have verbose options, however is a python script and can be easily modified to add debugging information.

@dkocher commented

This fails due to optimizations in 0f7e3fb. To list children of a container, we pass an empty string for the path URL paremeter like path=. If ommiting this, we succeed getting a directory listing but this includes all objects in the container making it highly inefficient. I suppose there is an issue in Swift that makes the empty path parameter work for some containers but others not.

@dkocher commented

Looking at it twice the issue is just that we only support hierarchical representation of files with existing placeholder objects present. Because there is no placeholder for the key /usr etc. we show no content.

@dkocher commented

Additionally the object name of these files starts with / which is not common. Even if there was a placeholder object usr in the container myfiles, we would find the objects within because we are filtering using a path of path=usr but not path=/usr.

@dkocher commented

I can't find any documentation in the OpenStack wiki, but we follow the recommendations of the CloudFiles developer guide here.