@dkocher commented

Is there a specific naming pattern you can see for these folders or other unique characteristics that may help me to reproduce the problem.

078fc51 commented

Here is a table of the folder names, a Y if they open in 3.2.1 an N if they don't and the number of files they contain...

||css||N||38
||dynamic||N||98
||files||Y||1
||flash||Y||1
||img||N||87
||js||N||26

The problem seems to be somehow connected to zero size files.

I looked in each of the above folders...

The 'files' folder which works in 3.2.1 contains one sub folder and nothing else. There are subfolders within that folder.

Folder 'flash' which also works on 3.2.1 contains a single .swf file.

All the folders that do not work with 3.2.1 contain a mixture of files AND subfolders. There all also contain some files with names like ajax_$folder$ which are 0B in size. I believe these are 'folder aliases' created by applications other than Cyberduck. We have used Interarchy and S3Fox previously. I've attached a screen shot of the js folder contents called js_folder.

To try and pin down the problem I thought I would download the js folder (being the smallest non working example), upload it with a different name and then delete the odd azero byte files to see if that made any difference in 3.2.1 but I'm actually having some trouble with 3.2

I received some errors, it doesn't seem to like the sub-folders. I got this message...

I/O Error: Cannot read file attributes
/mybucket.name.edited/js/ajax
S3 GET failed for '/js%2Fajax'

The forward slash between the js and the ajax is being escaped?

I got similar messages for 'ticker' and 'js'. All 3 are zero B files.

However despite the error messages the folder did download (see second screenshot js_folder_desktop)

I uploaded a copy of the folder, calling it js_copy with no errors.

I then opened this newly uploaded js_copy folder in 3.2.1 with no problem, I am still unable to open the original js folder in 3.2.1

0180f64 commented

I've pinned this down to a zero byte file inside folders created with Interarchy. I've tested with the latest version Interarchy 9.0.1/5484 and this is 100% reproducible.

Create a folder in your S3 bucket using Interarchy. Put a normal file inside. In this case 'test.txt'

Launch Cyberduck 3.2.1 open the S3 bucket, try to open the folder. "Request Error.. Not Found."

Using Cyberduck 3.2 open the S3 bucket, open the folder, see the 'test.txt' file. No problems. Notice also a zero byte file with the same name as the parent folder.

Delete the zero byte file, you will need to use S3Fox (or maybe some other S3 apps but not Cyberduck that doesn't seem to be able to delete it).

Now use Cyberduck 3.2.1 again, open the S3 bucket, open the folder, see the 'test.txt' file. No problems.

While I suspect Interarchy is to blame here, this did work in Cyberduck 3.2 but is now broken in Cyberduck 3.2.1

@dkocher commented

Thanks very much for the detailed report. I will look into this as soon as possible.

@dkocher commented

Replying to [comment:4 Paul Willis <info@…>]:

I've pinned this down to a zero byte file inside folders created with Interarchy.

What Interarchy does is create keys named /bucket/folder/ where the full key is folder/ but if displayed hierarchically the last part of the key is an empty string. Cyberduck always normalizes path references internally therefore this actually points back to the parent key.

@dkocher commented

In 4981.

kiddailey commented

Just FYI for those that stumble on this as I did:

-Be warned that you should not use 3.2 to delete the 0byte files causing this issue, or you may loose files!*

I reverted to 3.2 to try and work-around this until the next update and discovered that when I tried to delete the 0byte file out of a folder, Cyberduck 3.2 immediately started deleting ALL files within that folder -- and it's pretty obvious why:

1.) /bucket/myfolder contains a file called "myfolder" that is 0bytes and 3GB of other files ...

2.) Cyberduck issues the command "Delete /buckey/myfolder" in an attempt to delete the 0byte file ...

3.) Poof!

4.) Spend the next few hours re-uploading 1GB worth of files that got wiped before you realized what was happening :)