This bug is even more generic as it means that when you install a RPM
the new app don't show up in the menu before you log out/log in.

After some discussion in #bugs, I'm marking up, since this would force
users to log in and log out to have programs show up.

Actually a new app WILL appear since the panel checks the ctime which
IS propagated correctly.  However for the nautilus editting,
monitoring is a must, however it's not fully implemented, not just
broken ....

It doesn't work here when new apps are installed, FWIW.

i'm working on this currently btw.

Alex, talk to me - whats up?
Are you fixing this? Is it fixed?
We want to release gnome-vfs 2.0 and I think this is our only 2.0.0
blocker bug. If you don't have time to work on it someone else can
have a try.

Please note, as George mentions this affects *nautilus* primarily, not
the panel menus. Panel menus do not use GnomeVFS monitoring (yet...
they should :-). I don't think this is really release blocking....

It is realease blocking.  without it we will get a lot of 'editting
menus in nautilus doesn't work' because you now have to hit the reload
button.

I can give this a go if alex is too busy, but I'm leaving saturday
morning for 3 weeks and doubt I will have time to completely finish
it.  Though since some monitoring is there (the module notices changes
on disk) it's only implementation of propagating that through the
monitoring framework.

Thinking about it more, this shouldn't be THAT hard.

Working on this currently so I'll assign to self

I think it will be enough for 2.0.0 to implement dir monitors.  The
CHANGED signal should be emitted when a file changes so this should
make nautilus work.  So I'll file another bug if that's what we'll do
that can be fixed later on.

sounds great George, although I believe Nautilus should do event
propogation internally if we turn off monitoring in the module
altogether, so that may be another option

Well I have the directory monitors pretty much implemented.  And
nautilus cannot do event propagation since it's a different process
that modifies the vfolder.

I have comitted something which I think works, at least ont he
vfolders side.  There could be some nautilus problem.  So now the
directory monitors are created and triggered correctly (test-monitor
works it seems).

Hmm actually this does need more work on the vfolders side as well. 
Since another process will only notice structural changes, so we
really do need per file monitoring.  Hmmm, that seems fairly simple to
add now that I know what's involved.

I'm just committing the rest of the monitors work (file monitors). 
However nautilus still isn't picking up anything even though the
monitors ARE getting emitted.  I'm not sure where the fault lies.  Can
someone with greater knowledge of nautilus and monitoring look at
this?  Or perhaps I'm not setting up/emitting the monitors correctly
on the vfrolders side, but I don't think so

Alex, Darin, any idea?

OK, I now know that the monitors ARE getting emitted and that nautilus
IS catching them by adding printfs in nautilus-monitor.c, so I think
this is now a nautilus bug.

Just to make myself clear, nautilus is catching the events but is not
updating the display.

Hmm, just thought of some cases I didn't handle correctly, so the bug
isn't completely closed on the vfolders side however that's only for
handling deleting and creating

George- should I reassign to nautilus when you're done?

I was done yesterday.  In fact I haven't even time to read my mail
right now, so I will not be doing anything else.  But I've implemented
and tested the vfolder part so I think it's in nautilus court now.  I
hope I haven't left any bugs in but I've tried not to.  But really
don't expect  anything from me for the next 3 weeks :)

I don't have much time to look at this. Perhaps i have some time
tomorrow. andersca said he would take a quick look at it.

Leaving as 2.0.0 for now and reassigning to nautilus-maint, but I
think at this point this is not worth holding up a release for.

Punting as per discussion with Alex.

[Search for 'luis spamming' to catch every instance of this email.]
In order to better track Sun's bugs for Sun and Ximian's internal use, I've
added a temporary keyword to some bugs. I apologize for the spam, and for the
use of an additional keyword, but this is the best way for Sun to track 'it's'
bugs without interfering with the community's own triage and bug behavior. If
you have any questions or objections, please drop me a note at louie@ximian.com
or email bugmaster@gnome.org for more open discussion.

Ok, I think I know why nautilus doesn't always get correct monitor :

This is only caused when using "applications:" or "start-here:", not
when using fully qualified URI like "applications:///" or
"start-here:///".. With fully qualified URI, everything works fine..

The attached patch fixes the problem in gnome-vfs so "applications:"
uri becomes "applications:///" when created (I think it is the
cleanest solution since, for me, applications: is not a canonical URI..)

...

After more tests, the gnome-vfs patch fixes problems when creating new
directories, remove files or directories, moving files but there is
still a problem when creating new launcher ..

Created attachment 9613 [details] [review]
Let's canonize "method:" into "method://"

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

Alex: is this the cause for what remains of bug 73773?

Ya, I believe that is only issue remaining with monitoring.

Alex: have you tested fcrozat's patch? does it work?

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

This is fixed in all aspects except for that described in bug 73773,
so I'm killing this old lumbering beast.

Tested with sun beta 2 build 4 package. In Editing menu 'New 
launcher ' and 'Make link' is not working.

Can we reopen the bug please.

Those aren't related to this bug. Please open new bugs for those
problems, prabhut.