After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 40779 - Monitor changes to files made outside Nautilus (using FAM?)
Monitor changes to files made outside Nautilus (using FAM?)
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Views: All
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Seth Nickell
Nautilus Maintainers
: 43957 46204 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2000-05-01 20:15 UTC by pavel
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to add FAM support to Nautilus (4.42 KB, application/x-gzip)
2001-09-10 01:18 UTC, Seth Nickell
Details

Description pavel 2001-09-10 01:18:15 UTC
Replace the existing code that explicitly forces updates during file operations.



------- Additional Comments From sullivan@eazel.com 2000-09-08 15:28:51 ----

Setting all bugs to P6 to start official bug-prioritization plan. Please don't
set the priority to anything other than P6 unless you've got the gold seal of
approval for doing so.



------- Additional Comments From eli@eazel.com 2000-10-16 19:43:16 ----

Batch-assigning QA ownership of remaining bugs to eli@eazel.com



------- Additional Comments From don@eazel.com 2000-12-18 19:34:26 ----

*** Bug 43957 has been marked as a duplicate of this bug. ***



------- Additional Comments From don@eazel.com 2000-12-18 19:37:16 ----

OK, I'm giving this the gold seal and moving it up to P4, since I think we want
to do this.  I've got to believe that it will take longer than two weeks to make
this happen, though.




------- Additional Comments From snickell@stanford.edu 2001-01-26 02:07:14 ----

Two weeks actually seems like a very liberal estimate to me. I cobbled together
a patch that did this one night with fam/imon, probably with some bugs (and
probably won't apply without big changes to the current codebase). Because the
updating framework is already there, the only that really needs to be changed is
the thing that initiates the signal, which Imon makes very easy. It even handled
file change signals and did things like update pixmaps and upper lefts when they
changed...



------- Additional Comments From darin@bentspoon.com 2001-01-31 15:02:34 ----

*** Bug 46204 has been marked as a duplicate of this bug. ***



------- Additional Comments From eli@eazel.com 2001-02-21 11:16:17 ----

QA Assigning to brett. Sorry for the spam.



------- Additional Comments From snickell@stanford.edu 2001-03-16 17:17:53 ----

If Pavel doesn't want this bug, or is willing to give it up, I'd really like to
do this...



------- Additional Comments From darin@bentspoon.com 2001-03-16 17:53:37 ----

Konqueror has this, it's probably not 2 weeks work, and everyone wants it. I'd
like to work on it.



------- Additional Comments From eli@eazel.com 2001-03-26 11:12:54 ----

QA Assigning to self.



------- Additional Comments From snickell@stanford.edu 2001-03-26 14:18:51 ----

Created an attachment (id=1442)
patch to add FAM support to Nautilus




------- Additional Comments From snickell@stanford.edu 2001-03-26 14:25:55 ----

Current issues with the patch are:

   - may not be hooked in to Nautilus in the best place (two line change to
move), I'd like advice on where to put this
   - deals with "changed files" by informing Nautilus that file has been
created, not sure what the best way to tell Nautilus a file was just updated. If
telling it the file was created *is* the right way, we should probably call
file_removed first.
   - Needs to overwrite monitors rather than continuing to register the same one
over and over, we should pass the clientid in and store it with requests.
Basically you should end up with one URI per location with a list of clientids
registered to monitor that URI. When the last clientid is removed from the list,
we inform fam we aren't interested in that directory anymore.
   - currently causes hashtable problems, but I think the above (and updating
properly) will fix them

I would really like to take this bug to completion...



------- Additional Comments From snickell@stanford.edu 2001-03-26 14:30:26 ----

oh yes, one other weird bug...

  - its too agressive on detecting changes for thumbnailing. For example, load
an image in GIMP from Nautilus, change the image and save it. Nautilus will
detect that the image changed the instant GIMP starts saving to disk and will
attempt to rethumbnail it, sometimes completing before GIMP is done saving
leaving a black band at the bottom of the thumbnail.

(on the other hand try downloading something, its pretty cool that the filesizes
update as the download is going :-)



------- Additional Comments From darin@bentspoon.com 2001-04-02 16:13:23 ----

Seth is going to work on this a bit more, maybe make a better patch. I'll
probably take over from him and finish up, depending on how far he gets in the
next couple of weeks.



------- Additional Comments From snickell@stanford.edu 2001-04-12 15:46:25 ----

nautilus-monitor.[c|h] has been committed. They'll probably need to be modified
slightly depending on the context the monitoring is added at. I'm trying to
catch up on coursework after GUADEC, but hopefully I'll have some availability
this weekend.



------- Additional Comments From darin@bentspoon.com 2001-04-16 16:04:08 ----

OK. This is done now. Time to start testing to see what it does wrong.



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 21:18 -------
Bug blocks bug(s) 45534.

The original reporter (pavel@eazel.com) of this bug does not have an account here.
Reassigning to the exporter, unknown@bugzilla.gnome.org.