ColdFusion S3 Implementation bug with metadata and ACLs

This post is more than 2 years old.

This find comes to me by J. J. Blodgett. He found the bug, asked me to confirm it, and I've been able to. It is - from what I can tell - pretty serious if you make use of Amazon S3 support in ColdFusion 9.0.1. The gist is this: Any call to storeSetMetadata on a file stored in S3 will remove ACL information about the file. Here is an example that demonstrates the issue. Note that I've removed my security tokens.

<cfset dir = "s3://s:f@s3.coldfusionjedi.com"> <cfset files = directoryList(dir)> <cfdump var="#files#">

<cfset acl = storegetacl(files[3])> <cfdump var="#acl#">

<cfset perm = structnew()> <cfset perm.group = "all"> <cfset perm.permission = "read">

<cfset perms = []> <cfset perms[1] = acl[1]> <cfset perms[2] = perm>

<cfset storeSetAcl(files[3], perms)>

<cfset md = {"Price"=99}> <cfset storeSetMetadata(files[3], md)>

<hr> <cfset acl = storegetacl(files[3])> <cfdump var="#acl#">

As you can see, I get a list of files and then return ACL information about the 3rd one. (There is nothing special about the 3rd one. For the directory of files I was testing with I used that file as my tester.) A new permission for everyone to have read access is added and set to the file. Next, metadata for price is added. When the storeGetAcl call is run again the ACL is back to what it was before the metadata change.

This isn't simply a caching bug for the request as I had though. I broke my code up so that on one request it updated the ACL and in another it changed the metadata. Even in that attempt the ACL was reset.

Unfortunately there is no real fix for this. Luckily if you reverse your calls (set metadata then set ACL changes) it works fine. Of course, I would be concerned about making any metadata change. For now I'd recommend getting the ACL, doing your metadata change, and then re-setting your existing ACL right back into the file. JJ filed a bug report for the issue that you can find here: http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=86224

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by Henry posted on 2/8/2011 at 12:54 AM

Reported the same bug last month: http://cfbugs.adobe.com/cfb...

Comment 2 by Raymond Camden posted on 2/8/2011 at 12:57 AM

Ah well shoot. Someone needs to go through the bug base once a month and write a blog entry highlighting the 'top' ones. :)

Comment 3 by JJ Blodgett posted on 2/8/2011 at 1:13 AM

I figured somebody else had to notice this. Doing a google search for "StoreSetMetadata StoreSetACL" returns a total of 6 results which includes one matching your post today. Would really be nice to be able to see results from bugs in there. I saw Henry's name on several posts related to the S3 stuff but didn't see any mention of that bug. I guess I'll have to start searching the bug DB separately when I don't come up with reasonable Google answers...

Comment 4 by Henry posted on 2/8/2011 at 1:16 AM

oh that's ok, Adam Lehman said the CF team loooves duplicated bugs on CFHour show #85. :)

Comment 5 by shawnbecker posted on 9/20/2013 at 11:27 AM

Well, here I was thinking I was doing something cracked. This still exists. This sort of sucks, as I'm making a site that will rely heavily on s3.

Comment 6 by Schuyler Colfax posted on 3/8/2014 at 7:17 AM

Has this bug been migrated to the new bugbase? I just ran into it on CF10, but couldn't find it in the bugbase.

Comment 7 by Raymond Camden posted on 3/8/2014 at 8:21 AM

No idea. I'd just search for "s3". I think I did so a while ago and saw a few of the issues there.

Comment 8 by itisdesign posted on 12/27/2014 at 9:02 AM

Just FYI, this issue still exists in CF11 Update 3 and has been filed as #3863487.

Thanks!,
-Aaron