Bug 445869 - gnomevfs file monitoring not working
gnomevfs file monitoring not working
Product: Fedora
Classification: Fedora
Component: gnome-vfs2 (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-09 10:56 EDT by Tim Waugh
Modified: 2015-03-03 17:32 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-09 01:29:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
monitor.py (1.29 KB, text/plain)
2008-06-04 09:22 EDT, Tim Waugh
no flags Details

  None (edit)
Description Tim Waugh 2008-05-09 10:56:42 EDT
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):

How reproducible:

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.
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.
Comment 1 Jef Spaleta 2008-05-09 14:59:47 EDT
'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?

Comment 2 Jef Spaleta 2008-05-09 15:18:18 EDT
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.

Comment 3 Tim Waugh 2008-05-12 05:13:35 EDT
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.
Comment 4 Jef Spaleta 2008-05-12 12:03:31 EDT
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.  

Comment 5 Rex Dieter 2008-05-12 14:24:36 EDT
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
Comment 6 Tim Waugh 2008-05-12 16:09:25 EDT
Then perhaps it's Fedora 8-specific?
Comment 7 Jason Taylor 2008-05-12 17:35:22 EDT
I am on Linux bruiser.localdomain #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 
Comment 8 Jef Spaleta 2008-05-12 17:41:46 EDT
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.


Comment 9 Tim Waugh 2008-06-04 09:20:25 EDT
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.
Comment 10 Tim Waugh 2008-06-04 09:22:07 EDT
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
Comment 11 Bug Zapper 2008-11-26 05:40:15 EST
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: 
Comment 12 Bug Zapper 2009-01-09 01:29:25 EST
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.

Note You need to log in before you can comment on or make changes to this bug.