Cyberduck Mountain Duck CLI

#5471 closed defect (thirdparty)

Folder contents not displayed in swift

Reported by: pedroperez Owned by: dkocher
Priority: high Milestone: 3.8
Component: openstack Version: 3.7
Severity: normal Keywords:
Cc: Architecture: Intel
Platform: Windows Vista

Description (last modified by dkocher)

A swift folder with a large number of files (7000+) works with "st" client but is not displayed in Cyberduck.

$ st -A -U system:root -K XXXXX list myfiles | more

...... 7000+ more files .....

Change History (9)

comment:1 Changed on Nov 24, 2010 at 11:09:21 AM by dkocher

  • Component changed from core to openstack
  • Description modified (diff)
  • Milestone set to 4.0
  • Owner set to dkocher

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

comment:2 Changed on Nov 24, 2010 at 11:11:03 AM by dkocher

Similar unresolved issue for Cloudfiles in #5350.

comment:4 Changed on Nov 24, 2010 at 12:40:32 PM by dkocher

For the particular container I get the following response

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

for the request to


with the following headers

X-Auth-Token: AUTH_tk2f0e65b3e530439a9e77a1779710a2f4
User-Agent: Cyberduck/4.0b7 (7726:7728MP) (Mac OS X/10.6.5) (i386)

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

comment:5 Changed on Nov 24, 2010 at 12:48:04 PM by dkocher

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

comment:6 Changed on Nov 24, 2010 at 1:00:50 PM by pedroperez

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

comment:7 Changed on Nov 24, 2010 at 1:29:26 PM by dkocher

This fails due to optimizations in r7219. 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.

comment:8 Changed on Nov 24, 2010 at 1:31:44 PM by dkocher

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.

comment:9 Changed on Nov 24, 2010 at 1:43:05 PM by dkocher

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.

comment:10 Changed on Nov 24, 2010 at 1:44:34 PM by dkocher

  • Resolution set to thirdparty
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.