Storage API renames all uploaded files

I'm having the same issue. In my custom module, I'm processing files in batch and Storage API renames them in a way like WishMasterNND described.

I found the similar issue: #961552: class DrupalStorageStreamWrapper->url_stat() - Filename not updating on mulitple files.. It's marked as closed but guess it still exists.
As a workaround, I commented out lines 580-582,584 of storage_core_bridge.module and it worked for me.

I'm using this module in conjunction with File (Field) Paths module so that I can set a tokenized path to the Amazon S3 bucket and subdirectory of my choice. I'm also doing things programmatically so I'm using the file_save_data() method to pass my data and a custom destination. If I comment out lines 580-582 but leave 584 (and comment out the closing curly bracket), it appears to preserve the file path and name I provide and store it in the correct path on S3. Hope this helps.

I'm trying to do similar to aviddv1 in #4 with Filefield Paths (I'm trying to use Tokens in the filename using field values from the node)... I tried the workarounds suggested, but it didn't work in my case. The file that appears in my S3 bucket retains its original filename as if Filefield Path's configuration is ignored.

I ran into this issue with files imported from the Feeds module and spent the better part of the afternoon trying to troubleshoot it as a Feeds bug until I found this issue.

Removing the lines noted in #3 from the url_stat() method did seem to solve the problem, but am still testing for side-effects.

From looking through the commit history, that code seems to be trying to avoid setting the global variable $storage_core_bridge_filename if $uri refers to a directory, but the test ($storage_core_bridge_dirname == $uri) appears to do that as well and if it's a directory it would return before hitting that code block.

Not understanding the use of the globals there, and I tried to refactor to use protected methods, but I couldn't get it working. I am having trouble wrapping my head around how Drupal calls these methods through file_save_data(). Will do some reading and see if I can come up with something better, but would be great if the maintainer could chime in and explain the thought behind this area of code.

PS to the maintainer - despite this minor issue, this module is *amazing*. Thank you...

Confirm the problem and workaround in #3 working.

So the way Core Bridge works is really a big hack.

Wish I'd written a comment for line 580. I'll need to be careful before removing that logic.

Commenting out the if statement does seem to fix the issue.

Though it seems that removing that if statement removes the deduplication functionality/check of storage api.

The gain of proper naming, over the loss of the deduplication, can be lived with.

I totally failed to document the purpose of that code. I have now removed it:

http://drupalcode.org/project/storage_api.git/commitdiff/82bb575

Don't know if it will cause something else to blow up.