Description of problem: It is possible to start revelation twice as the same user, and potentially lose data. Version-Release number of selected component (if applicable): revelation-0.4.11-3.1 How reproducible: 100% Steps to Reproduce: 1.Start revelation, [open the data file if not already configured to do so automatically] 2.Add a new account and generate a password for it. 3.Save changes. 4.Now minimize the window or lose it behind another window. 5.Start revelation, [open the data file] 6.Make some trivial change. 7.Save changes. Actual results: Generated password is lost. Expected results: Second revelation instance should warn that revelation is already running.
'We' have a problem.... upstream revelation is essentially unmaintained and has been since October. I'm not sure what to do about that in the long term. I'll poke at doing a patch but, I certainly don't want to collect downstream patches inside the Fedora package over a multi-release cycle. Are you looking for a big lock like yum uses? -jef
Are you not seeing the creation of a dialog window that tells you the contents of an open file have changed? Here's what I did. start revelation instance 1, unlock a password file in it start revelation instance 2, unlocak the same password file create a new entry in revelation instance 2, save the file instance 1 notices the file change and generates a dialog asking me to reload the file. This is exactly the same sort of behavior that gedit does when it notices that an open buffer has been changed. I'm not sure there is a need for a lock here. -jef
No, I don't see that. I'm trying on x86_64 if that makes a difference. I start instance 1 and 2, unlocking the same password file in both. Now I create a new entry in instance 2 and save the file. No dialogs appear. I click 'Save' in instance 1 and close both instances. Start revelation again and unlock the password file. Newly created entry is gone.
whoa, now that is unexpected. I'm going to need help tracking down what is potentially a 64bit specific behavior since I don't have a 64bit box. Reading the python, the logic for file monitoring is using gnomevfs.monitor_add(file_normpath(file), gnomevfs.MONITOR_FILE, callback) buried in a layer of callbacks in io.py This is exposed via the __cb_file_content_changed callback in /usr/bin/revelation which calls the the FileChanged dialog defined in dialog.py I'll work on instrumenting the files so you can capture some console output and we can see what's going on different on your system than mine. -jef
I can confirm Jef's findings in comment #2, on saving instance 2, instance 1 gives "The current file '...' has changed. Do you want to reload it?" on f9/x86_64, revelation-0.4.11-4.1.x86_64
Then perhaps it's Fedora 8-specific?
I am on Linux bruiser.localdomain 2.6.24.5-85.fc8 #1 SMP Sat Apr 19 11:18:09 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux and I cannot reproduce the error. I receive a message that the content has been updated do I wish to reload, clicking yes, reloads the file correctly with all pertinent/correct information.
So, where does that leave us? Tim, my only guess at this point is the gnomevfs file monitoring is not working for you. If that's the case, then its probably not revelation specific and should be reproducible with anything that uses the python bindings for gnomevfs. Is the key file sitting on a remote network location perhaps? I'm not aware of any inherently limitations on the ability of gnomevfs to monitor for file changes, but at this point i'm grasping at straws. -jef
No, everything is local. I have managed to try out the GnomeVFS python bindings, and can confirm that file monitoring is *not* working correctly for me.
Created attachment 308340 [details] monitor.py gnome-vfs2-2.20.1-1.fc8 I get this output from 'python monitor.py': $ python monitor.py GnomeVFS monitoring is NOT working If I try that on Fedora 9 I get this: $ python monitor.py Got monitor callback GnomeVFS monitoring is working
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.