We are pleased to announce that we have released the updates for the following ColdFusion versions:
The updates fix bugs that were reported in the previous update release.
We had previously released the preview updates of these releases. If you had applied the preview updates, you can retain the preview builds. You must however revert the update URL to the default one to receive future updates.
If you will be using the Administrator interface to perform the update, note that you must first update to Update 11 for ColdFusion (2016 release) or Update 4 for ColdFusion (2018 release) due to a recent change in code signing certificate, which is used for verifying the download of the update.
These are mandatory pre-requisites before updating, unless you download the update yourself and apply it manually.
We also recommend that you upgrade the web server connectors after applying these updates.
The following are links to the tech notes for each update:
What’s new in this update
We’ve fixed bugs related to core language, connectors, and other areas. For more information, see the list of bugs fixed:
Please update your ColdFusion versions today. Let us know if you face any issues while installing the updates. Your feedback is essential to further enhancing the product.
We thank you for your continuing support.
Copy link to clipboard
Would we need to fix the Error after accessing ColdFusion Administrator using the connector port if we do this update? I know that in the previous update we had to reconfig the isapi_redirect.dll.
After applying the update we could no longer connect to Amazon S3 in the standard format s3://accessKey:secretKey@somebucket/somefile.txt
It throws an error, "Attribute validation error for tag CFFILE...".
We needed to go back to CF 2018 update 5 to be able to work with Amazon S3 again. Is this a known bug?
Tolgar, it's understandable to be left thinking, "the cf update broke cf" but that's rare, and it may not be what it seems to you. Here are a few thoughts that I hope may help:
So it would seem odd for this update 6 to have had the impact on s3 you were experiencing. Check first if you had 0 errors in the install log (see my post for where to look, which is not obvious). It will still be there after your reversion to 5. If you had any, see my post post for how to try again. Or try 7, and again confirm 0 errors after that.
Then let us know where things stand or any other feedback you may have, while awaiting any other possible answer from Adobe or others here.
Thanks for your reply. I can confirm that the update to 7 is not to blame, it works fine and without any issues on other servers. I couldn't yet pinpoint why there is this problem with that one server, but obviously it's something specific to some other code specific to that server.
So thanks, the update 7 itself works fine.
OK, but are you saying that you have one server where update 6 (and 7) still "do not work" for you? If so, did you consider the link I shared, for checking if anything went wrong in the update log? If I've misunderstood, please clarify the situation with the "one server" and whether you are wanting to resolve it.
Apologies for the late follow-up. While most scripts work fine, the following is where I think we might have bug?
1) Upload a test file to S3, call it "testfile.txt".
2) Try to run a simple: #fileExists(s3://[YOUR LOGIN]@[YOUR PATH]/testfile.txt)#
3) Reply states: YES (file does exist)
4) Try again, but rename file and code to "testfile+bug.txt"
5) Reply states: NO (file does not exist). This is wrong.
So as soon as a filename contains some common special characters like "+", "(", or ")", simple operations like fileExists using the built-in "s3://" protocol no longer work,
The same can be observed with CFFILE operations, like "copy", "move", "rename", "delete". The error messages vary here, but it's the same pattern. Any "s3://" operation works fine for most file names, but won't work with file names containing special characters like "+", "(" or ")".
It also doesn't make a difference if I "encodeForURL()" the filename, or try other methods to encode the filename.
The above behavior can be replicated from CF2018 update 7 on up. The last version where it works fine seems to be CF2018 update 5.
Tolgar, as you feel this is clearly a bug introduced by update 7 and above (based on your experience), you really should create a bug report at tracker.adobe.com. That's where Adobe tends to bugs (and they really do), whereas they don't tend to reply here. (Do be sure to confirm that it still happens on update 10, from last month, before reporting it.)
One thing in the meantime: there was a discussion by Ben Nadel several years ago on this topic, where he explained why just using urlencode was not enough to deal with such special chars in s3 object names. Maybe what he suggests could work for you while you wait for this to be resolved by Adobe.
That's great advice, I just submitted the bug report.
Thanks for all you do, Charlie! It's much appreciated.
Tolgar, any thoughts?
See his response above (on Feb 10).