When auto-open a revelation password file, it gives an error

Bug #96968 reported by Hendrik van den Boogaard on 2007-03-27
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Revelation - obsolete
revelation (Debian)
Fix Released
revelation (Ubuntu)

Bug Description

Binary package hint: revelation

Feisty-Beta, Revelation 0.4.11-0ubuntu3

When in preferences 'Open file on startup' is set to a password file it seems to work, but as soon as the 'master password' for this file is given, it will give a error message (see attachment). On my computer the password file is located in a directory with a 'space' in the name. When I move the password file to a directory without a space, it works ok. The error also hints to a 'directory not found' and if I open the preferences screen after the error occurred and I press Continue, it gives a new error (attachment 2).

So workaround: move the password file to a directory without spaces in its name

Related branches

description: updated
Jérémie Corbier (jcorbier) wrote :

It looks like revelation uses gnomevfs,URI to handle paths internally. Spaces are escaped by replacing them with %20 (I guess other characters like é cause the same issue).

Changed in revelation:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Changed in revelation:
status: Unknown → New
Iván Campaña (ivan-campana) wrote :

Confirmed to happen when the URI contains special characters, in my case with the ñ. Opening the same file on the same location manually (through the file open option), it works ok, no problems at all.

Traceback (most recent call last):
  File "/usr/bin/revelation", line 274, in <lambda>
    self.datafile.connect("changed", lambda w,f: self.__state_file(f))
  File "/usr/bin/revelation", line 491, in __state_file
OSError: [Errno 2] No existe el fichero ó directorio: '/home/amauta/Amauta/Contrase%C3%B1as'

This patch for src/lib/io.py seems to work. It just unquotes any escaped special characters in file URIs passed to "file_normpath", using the urllib.unquote() function.

More info at:

I haven't tried the patch suggested above but I can confirm that the problem still exists in version shipped with the current beta of Ubuntu 8.10.

Jonathan Moisan (jmoisan) wrote :

I confirm that the problem still exists in version 0.4.11 shipped with Ubuntu 8.10 (patch not tried).

Nikola Kasabov (nikaas) wrote :

Same error here:

Traceback (most recent call last):
  File "/usr/bin/revelation", line 274, in <lambda>
    self.datafile.connect("changed", lambda w,f: self.__state_file(f))
  File "/usr/bin/revelation", line 491, in __state_file
OSError: [Errno 2] No such file or directory: '/home/umb/%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B8'

(Cyrillic characters in path)

Ubuntu 8.10 , Revelation 0.4.11 , no patch

Although the bug persists, there is quite an easy workaround for this:

* Instead of opening Revelation and configure it to open a password file on start up, open the password file directly. Gnome has associated the application to open the password file with (which is Revelation) and will start Revelation without problems and directly with your password file. You can also change the shortcut from Revelation itself to your own password file.

Nikola Kasabov (nikaas) wrote :

In my case (maybe with others too) using a file for 'starter' is not an option because I use Revelation applet and I start the program and the file from there. And I want to continue to use the applet for it's other useful options like unlocking file only for viewing or searching within applet.

It's not big deal but will be good if corrected.

Changed in revelation (Debian):
status: Unknown → Confirmed
Tony Arnold (tony-arnold) wrote :

This bug is still present in the version shipped with Ubuntu 9.10 (it's the same version as came with 8.10 by the looks of things, 0.4.11).

Is revelation no longer being developed? Is there an alternative?

I have a fix for that in -5, which is not yet in debian, available from the git repo:

git clone git://bc-bd.org/git/revelation.git/

And yes, upstream is dead. I tried to find a python developer willing to continue the work, no luck so far.

An alternative IMHO is keepasx. No migration tool though.

There has been a little work from others, including myself, in branches/forks upstream, but no official activity since conversion to Mercurial 7 months ago.


I have two patches in above git repo (branches named after the debian bug nr) for two debian bugs. Those patches are based on forks mentioned in #13. However I was unable to get them to work.

Bart Veldstra (ghostonline) wrote :

Applied the patch in comment #5 to the source package.

Evan Broder (broder) wrote :

Bart - that patch looks mostly good. But since revelation is already using dpatch to manage patches, can you rework your debdiff to add an additional dpatch instead of applying directly against the source tree? See <https://wiki.ubuntu.com/PackagingGuide/PatchSystems> for more information.

Also, if I were uploading the patch, I'd just fix this myself, but please also update the changelog entry for Lucid instead of Karmic.

Changed in revelation (Ubuntu):
assignee: nobody → Bart Veldstra (ghostonline)
status: Confirmed → Incomplete
Evan Broder (broder) wrote :

I've unsubscribed ubuntu-universe-sponsors until the patch gets fixed as noted above. Feel free to resubscribe when that's been done.

Bart Veldstra (ghostonline) wrote :

Hey Evan, I did as you asked and recreated the package using the dpatch system. Regarding you comment about the distribution in the changlog, I presumed this was merely changing 'karmic' to 'lucid' in my changelog entry. Am I correct about this?

Changed in revelation (Ubuntu):
status: Incomplete → Confirmed
assignee: Bart Veldstra (ghostonline) → nobody
Benjamin Drung (bdrung) wrote :

Yes, that's right.

Thanks for your patch. I uploaded it now with a small change: I used the information from debian/changelog for the patch header (sponsored debdiff attached). Please forward 94_url_decoding.dpatch to upstream and Debian.

Benjamin Drung (bdrung) wrote :

Forgot to add the patch. Here it is.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package revelation - 0.4.11-4ubuntu4

revelation (0.4.11-4ubuntu4) lucid; urgency=low

  * add 94_url_decoding.dpatch to fix LP: #96968
    - Patches io.py to unquote file url during the
      normalisation process
 -- Bart Veldstra <email address hidden> Sun, 03 Jan 2010 19:53:26 +1100

Changed in revelation (Ubuntu):
status: Confirmed → Fix Released
Changed in revelation (Debian):
status: Confirmed → Fix Released
SerP (serp2002) wrote :

how i fix that in karmik?

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

Other bug subscribers

Remote bug watches

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