Red Hat Bugzilla – Bug 445869
gnomevfs file monitoring not working
Last modified: 2015-03-03 17:32:37 EST
Description of problem:
It is possible to start revelation twice as the same user, and potentially lose
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Start revelation, [open the data file if not already configured to do so
2.Add a new account and generate a password for it.
4.Now minimize the window or lose it behind another window.
5.Start revelation, [open the data file]
6.Make some trivial change.
Generated password is lost.
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?
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
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.
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.
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 188.8.131.52-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
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.
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]
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:
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.