webOS 2.X bug could cripple reinstalled node.js + db8 apps | webOS Nation

webOS 2.X bug could cripple reinstalled node.js + db8 apps 39

by Derek Kessler Thu, 14 Apr 2011 8:02 pm EDT

One of the touted features of webOS 2.0 was that developers could used node.js services and db8 databases to make for apps that were faster, better, and easier to code. It’s good stuff, and though admittedly over our head, we can appreciate how well it works when an app like Email just flies on our Pre 2.

But it turns out there’s a problem, and it’s not with node.js or db8, but more how webOS 2.0’s app deleting system works. As was discovered by WebOS Internals, an app that uses node.js and db8 won’t delete properly. The app will be gone and all, but the file setting the permissions for that database will stay behind. Since you’ve deleted that app, you might be slightly peeved that there’s a tiny file taking up a trivial amount of space on your phone, but that’s not the issue here. The issue is that when you reinstall that app, the configurator process sees that there’s an already configured permissions file in the cache directory and skips applying any permissions, meaning that the app can’t access the database at all.

That, dear reader, is a problem. This issue becomes worse in that the only way to clear that file out of the cache directory is to erase the device or run the webOS Doctor. In short, there is no way for average Joe user like most of us to correct it, short of going nuclear.

As a number of WebOS Internals apps, like Tweaks and ModeSwitcher, have been built or rebuilt for webOS 2.0 using node.js and db8, they saw this as a problem. The workaround, which was first implemented in Tweaks, isn’t exactly elegant, but it does the job. Tweaks has been updated with a homebrew pre-remove script that forcibly deletes the permissions file from the cache directory when the Tweaks node.js service is removed. But to do this, the pre-remove script has to have already been in place, which means that making it work requires deleting, reinstalling, deleting again, and reinstalling again to make the magic happen (and removing your preferences in the process).

This homebrew script could obviously be implemented into any other homebrew apps that utilized node.js and db8, but App Catalog apps are a different story, as they don’t have access to the same kind of post-install and pre-remove scripts as the homebrew crowd. The best solution is going to have to come from HP in the form of an update to webOS, which will hopefully come soon. In the meantime, we don’t recommend you go deleting any apps you intend to use again sometime soon. It could get messy.

Source: WebOS Internals (Twitter); Thanks to Rod Whitby for the additional info!


I bet H/P is not even working on 2.x, probably concentrating on 3.0

It's still not any actual news if only .3% of palm users can get their hands on 2.X.

You're just pulling percentages out of your ***.

Hey you know it's true. Its the only reason you're bashing at me anyway. And at leased I know what percentages are.

No, you don't know what they are since you're making them up.

"at leased I know"

lol your point is well understood

This sucks, cause it apparently happened to my Koto Player installation. I can no longer use Koto Player, its broken and the media IPK doesn't fix it. Is there a way to manually delete this file from Internalz afer the delete of the app, and then a reinstall might work? This is ugly as those of us on Meta 2.1 most likely won't get another version..

Considerably nice content, this kind of post is definitely good along with intriguing one for readers.

I thought everything was being kept in a cloud. EPIC FAIL :P

The apps download from the cloud, but they fail to install because of a local permissions issue. So the cloud is not the issue.

Could you bundle a service with your app to check the permissions, and correct them if necessary?

No. App Catalog apps can't do everything that homebrew apps can. It's a security thing.

Is there any more specific technical details about this bug? I looked on the @webOSInternals Twitter channel and couldn't find anything.

Does this bug only manifest itself if a node.js service accesses the db8 database? Because my app uses db8 and has a node.js service and has not experienced this issue (not working after being deleted and re-installed). I know this because I've deleted my app tons of times during testing. However my node.js service doesn't access db8 so that's why I was wondering if that's the specific combination that triggers the bug.

That is correct. It's when the node.js service is used to access db8.

I asked Rod to explain it to me the other day, and my understanding of it is that it affects permissions, which your own app doesn't need if it is accessing db8 databases which it created for itself. So since your app is the only one accessing it's db8 database, you would not be experiencing this problem. I think the problem with node services comes when you need to add separate permissions for node to access your db8 databases.

Isn't there technically only one db8 database?... I think when you "create" a db8 database you just get your own chunk of the one. Kind of a tangential issue, but just was thinking about it when I read your comment...

Meh, I prefer to think of them as separate databases instead of separate chunks of one database.

What is up with the accompanying illustration? It just seems like a totally random combination of things.

It's a bug... attacking the node.js logo... in the Palm HQ lobby.


It's a bit of a stretch in my opinion.

stupid hp. 48,000+ engineers. more like 48,000+ dishwashers

You do realize that HP does much more than just webOS, right?

HP is also placing a whole lot of eggs in the webOS basket. Presumably a bug like this should be considered very serious for HP.

Yet, they still do much more than just webOS.

"webOS 2.X bug could cripple reinstalled node.js + db8 apps"

I think that's in english but i'm not positive.

oh man. losers.

makes me wonder what kind of testing goes on there....that is a very major scenario to test !!

The bug that prevents apps on phones updated OTA to 1.4.5 from saving to the user's USB partition is also a major scenario they forgot to test. That was another bug that the user had to doctor (or get a workaround from webOS Internals, as is the case here) to fix. And on 2.1, the media indexer bug that breaks Music Player Remix and other bugs that depend on the media indexer is another major bug they apparently didn't catch in testing.

It does make you wonder what testing they do...

Don't forget the fatal Luna bug which prevents Node and PDK apps from working together. ARRGGH!!

I'm not sure that's a bug, more like a design limitation.

Wonderful. I guess that's why I can't download 'framework' and 'device behaviour' patches....

can we have a list of apps affected?

I was planning a trip back to 1.4.5 to grab my Sprint PRL update then back to 2.1. Does this mean I should hold off on that?

dont think you will have a problem since u will be doctoring...

is this problem related to the one that removing of synergy apps before removing the account can defunct the whole synergy db? This was first mentioned by Chapura.com


Switching to 4G Android until HP gets their act together!

Perhaps in 2 years the phones/tablets will be cutting edge when released. Now, they're not even cutting edge when announced.

WebOS is great, but...that's not enough any longer for me.

LearnMax is one of the largest offering in Learning and Knowledge management solutions
long Term Evolution

Thanks for providing such a nice information related to that topic.
Free Local Listing

Check this out Press Release Service.