Where are the important informations for AIR 3.4 that, the store path of the ELS files are changed and so all data is lost.
Additional if the ELS access is not capsulated with an try-catch-final a fatal error is thrown.
This is the page for AIR for HTML. You want http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/data/EncryptedLoc alStore.html
Also, be sure that your filter settings on that page are for Flash Player 11.4 and AIR 3.4
Hope this helps,
Senior Content and Community Manager
there seems to be definitly a bug for AIR 3.4 (Actionscript).
I am additional in the prerelease forums for AIR 3.4,
there had been started an own thread.
In the thread is a report about more than thousands of affected users.
For myself I can confirm that Mac and Windows versions are affected.
Please contact someone from the AIR development team, every hour counts now, I think.
Thanks for the heads-up. I just pinged the product team.
I want to give you an update on where we are with this issue. We understand the severity of the problem and are actively investigating both bug fixes and workarounds. I hope to have more info later today or Monday at the latest. In the interim, please take a minute and vote/comment for the following bug:
If possible, please include a link to your application (or a sample app) and steps to repro. We'd like to make sure we include this in all future testing so this does not occur again. If you'd like to keep this private, please feel free to email me directly at firstname.lastname@example.org
All info is now sent to your private email acc, and also updated in bugbase (bug 3315763).
Thanks you. No new information to give out yet. To get an idea of the data we're talking about here, is this primarily just user credentials that have been reset?
Everything on ELS. We store FB token, LastFM token, and other client related service credentials that varies in the different countries we operate.
We are using ELS to store login datasets and other data, which should not be manipulated by the user like database keys.
In short: things which are "app secrets" which need to be secured by the system keychains
or in other words, informations for which ELS was designed.
Before FOUR days we have reported this bug to Adobe and the only thing is today, that Adobe is asking in which use cases we are using ELS?
I hope this is not genuine?
Is Adobe continuing the AIR 3.4 roll out?
To point it directly out:
We need a fix asap.
Otherwise I think every developer and every company has to rethink (or is rethinking) about the use of AIR.
In our case we have an encrypted database - using air.SQLConnection() - that we generate a random encryption key for the user. We then store the encryption key in ELS. No key means unable to open the database and apparent data loss in the database.
Hello AIR developers,
I want to thank you for your patience and again apologize to you for catching you off guard with this change. Our team met today and our immediate plan is to roll the ELS changes back to the AIR 3.3 level. We are working on a timeline for when this update will be occur. We are treating this with the highest priority and expect it will not take long.
For those interested, here’s how and why this change occurred. Over the past year or two we’ve heard complaints about the reliability of our ELS implementation, especially on the Mac platform. We’ve known all along that we wanted to refactor this feature and remove dependence on third party libraries. We undertook this restructuring during the 3.4 release schedule and finished without hearing any major complaints from our internal or prerelease users. One assumption we made was that ELS data was treated like a volatile cache. In the past we’ve given guidance on the usage of ELS in both blogs and our help documentation, suggesting that developers should not depend on ELS as permanent data storage because it “can be lost for a variety of reasons”. Our position on this hasn’t changed, but we acknowledge and understand that some applications have come to depend on this data and if at all possible, we should do our best to persist it.
Going forward, we will most likely reimplement our changes from 3.4, however when doing this we will also work to provide a way to automatically upgrade and persist your application's data. We will also give plenty of advanced notice and make releases available on our labs.adobe.com site. We want this change to improve your lives by adding improved stability and we look forward to working with you on this in the future.
While we work on implementing the changes I’ve previously described, we plan to disable the automatic AIR 3.4 update notifications that users are currently being prompted to install. Our hope is that this stops the spread of this issue and reduces the support required for you and your customers. Both the AIR 3.4 SDK and runtime will still be available for manual download via adobe.com. We will provide further instructions and information early next week.
Official statement - http://blogs.adobe.com/flashplayer/2012/09/air3-4els.html
The update mechanism should now be turned off, we're working on rolling back the ELS changes and it should be included in our next update.
If you haven't seen the news, we've released our first beta release of AIR 3.5. This build contains the roll back of the ELS implementation to the AIR 3.3 level. We plan on updating AIR 3.4 with this change within the next week or so. When you get a chance, please give this new runtime a try and let us know if you run into difficulties.
Please be aware that any data saved with ELS using AIR 18.104.22.1680 will be "lost" when we switch back to the 3.3 ELS implementation. While your app won't be able to access this data, the two data stores should be able to co-exist.
On Windows Vista and 7, AIR ELS data is located here:
In AIR 3.3 and earlier, in the upcoming AIR 3.4 update, and in AIR 3.5, ELS uses 4 separate files:
In the current version of AIR 3.4 (with the "new" implementation), ELS uses just a single file:
If you run into problems, please try deleting or renaming the PrivateEncryptedData* files in case stale data exists.