Error:file is encrypted or is not a database

Bug #314777 reported by lilbudda
36
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-rdp (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: gnome-rdp

Error in query:
SELECT * FROM version WHERE id=1
Error:file is encrypted or is not a database

Upgraded to Jaunty on 1/6/2009 from Intrepid. After launching app, got the previous error message.

Revision history for this message
Alex K. Grinko (nitrogear) wrote :

New version of gnome-rdp uses sqlite 3.x, but database file .gnome-rdp.db (in user's home) has version 2.x.
You can move file .gnome-rdp.db to .gnome-rdp-2.db and gnome-rdp will work, but you need to create sessions again.
Can someone tell how can I export data from sqlite database 2.x and import it to 3.x?

Revision history for this message
Aaron C. de Bruyn (darkpixel2k) wrote :

Thanks for the pointer Alex--I wasn't sure what the problem was--but I do know databases.

I compared the old database to a new one on a clean install. Apparently it's not just sqlite2 vs sqlite3--there's also a table used by the new version that must be created.

I have a quick work-around below--but the real solution would probably for the gnome-rdp people to detect the database version and perform an update from within gnome-rdp.

Workaround:
Make sure gnome-rdp is closed.
Open up a terminal and run the following commands:

killall gnome-rdp.exe
mv .gnome-rdp.db .gnome-rdp-backup.db
sqlite .gnome-rdp-backup.db .dump | sqlite3 .gnome-rdp.db
sqlite3 .gnome-rdp.db "CREATE TABLE appOptions (name VARCHAR(300) PRIMARY KEY, value VARCHAR(300));"

An explanation:
The first line will make sure gnome-rdp is not running.

The next line moves the database named '.gnome-rdp.db' to '.gnome-rdp-backup.db' because we need a backup in case there's something I missed, so we can restore it later.

The third line tells the old sqlite 2.x to open the backup database and dump out it's contents--then pipe it into the new sqlite3 database.

The last line tells sqlite3 to create a table called appOptions in the database. This is apparently required by the newer version of gnome-rdp.

Revision history for this message
Erik Meitner (e.meitner) wrote :

Same problem here after upgrading to jaunty from intrepid.
Aaron, thanks for the quick fix.
It should be trivial to add a database check and upgrade process to the app. Anybody know Mono?
At the very least, a shell script based upon Aarons procedure that a person can be instructed to run. I would add "sudo apt-get install sqlite sqlite sqlite3" as many systems may not have these installed.

Revision history for this message
James P Michels III (james-p-michels) wrote :

The newer gnome-rdp should automatically add the appOptions table on startup if it's not already present.

Kees Cook (kees)
Changed in gnome-rdp (Ubuntu):
status: New → Confirmed
Revision history for this message
Mick K (mjkemsley) wrote :

There also appears to be a few schema changes in the session table.
The length of a few fields were changed from 30 to 300 (apparently length on a varchar in sqlite is only cosmetic, so it probably wont affect anything)

I used the following to get gnome-rdp to create the new database, and then just used sqlite dump to copy over the data

mv ~/.gnome-rdp.db ~/.gnome-rdp-old.db
#Open gnome-rdp to create new database, then click File->Quit
gnome-rdp
sqlite ~/.gnome-rdp.old.db ".dump session" | fgrep INSERT | sqlite3 ~/.gnome-rdp.db

A number of guys at work use gnome-rdp, so I wrote a quick bash script to do this with a few sanity checks. I'll attach it in case someone finds it useful
Just give it execute permissions, and run from a shell

Revision history for this message
Mick K (mjkemsley) wrote :

Sorry there was a typo in that last comment. It should of been:

mv ~/.gnome-rdp.db ~/.gnome-rdp.old.db
#Open gnome-rdp to create new database, then click File->Quit
gnome-rdp
sqlite ~/.gnome-rdp.old.db ".dump session" | fgrep INSERT | sqlite3 ~/.gnome-rdp.db

Revision history for this message
jbfoley (jbfoley) wrote :

I've tried both methods (Mick's and Aaron's) and both result in gnome-rdp becoming unresponsive when it is restarted.

I had encountered this same problem when going from 7.04 to 8.10 and solved it in a similar way, by re-importing the database in a different version (I'll edit in the reference if I can find it.) Now I get the same thing after upgrading to 9.04 (I wish they'd just pick one database version and stick with it.

Is it possible that the fix is not working for me because of the earlier fix? If so, is there anything I can do to get this working? My database has more than 300 entries, so re-entering these from scratch is not really an option.

Revision history for this message
jbfoley (jbfoley) wrote :

Scratch that last post: Mick's script worked on the second try after a reboot. I was using several different backups of the original .gnome-rdp.db to try the different methods and probably used one that had been partially processed already as the seed for the script.

Aaron's method still did not work for me with the correct backup, and I'm pretty sure I had it right when I tried pasting in Mick's commands (i.e. not using the script) so there may still be a typo in those.

I should add that I'm using the release version of 9.04, not the alpha.

Thanks for the awesome script, Mick. You saved me a *lot* of trouble.

Revision history for this message
Mick K (mjkemsley) wrote :

jbfoley, good to hear it helped

I had a similar issue with it being extremely slow and found disabling the keyring fixed the problem (unchecked Options->Use Keyring in gnome-rdp). I have about 150 Session names and none of them have a saved password.
At the bottom of the script I set use keyring to false, which might explain why only that script worked

I think this may be an unrelated bug when gnome-rdp has a number of session profiles with use Keyring enabled.

Revision history for this message
Reinier Post (reinpost) wrote :

gnome-rdp should do the upgrade automatically ...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.