Matt Keenan wrote:
I'm seeing a unique issue with pkg, where Creation FEN (File Event
Notification) is not being sent.
gamin is used by gnome-panel to monitor /usr/share/applications and
other directories. This is the default .desktop directory where
applications being
installed place their .desktop file in order for the application to appear
in GNOME menus.
As this dir is monitored changes made here are reflected dynamically in
the gnome-panel menu structure e.g. installation of a new .desktop file.
I've just noticed that when installing SUNWgftp package which does
create gftp.desktop in /usr/share/applications, is not resulting in a
Creation Event
being fired, and thus does not appear in the gnome-panel menu dynamically.
See bug : http://defect.opensolaris.org/bz/show_bug.cgi?id=10194
Directly accessing the a file in this directory, e.g.
cp /usr/share/applications/gftp.desktop
/usr/share/applications/gftp-2.desktop
Does result in a creation event and you end up with two entries in the
menu.
pkg uninstall SUNWgftp, does cause a Deletion event to be fired for
gftp.desktop.
So I'm asking does pkg install do something funky to circumvent FEN ? Or
would this be seen as a possible bug in FEN ?
This is either a bug in gamin or gnome panel. Here's what I've found.
If I create a package with just one file (and
/usr/share/applications/foo.desktop file) and install it, I *almost*
always see the icon, here are the events (along with the related
filename) I see:
CPU ID FUNCTION:NAME
0 62257 default_event_converter:return
G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED
0 62256 g_file_new_for_path:entry /usr/share/applications
0 62257 default_event_converter:return
G_FILE_MONITOR_EVENT_CHANGED
0 62256 g_file_new_for_path:entry /usr/share/applications
0 62257 default_event_converter:return
G_FILE_MONITOR_EVENT_CREATED
0 62256 g_file_new_for_path:entry
/usr/share/applications/test.desktop
If I uninstall it:
0 62257 default_event_converter:return
G_FILE_MONITOR_EVENT_DELETED
0 62256 g_file_new_for_path:entry
/usr/share/applications/test.desktop
0 62257 default_event_converter:return
G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED
0 62256 g_file_new_for_path:entry /usr/share/applications
0 62257 default_event_converter:return
G_FILE_MONITOR_EVENT_CHANGED
0 62256 g_file_new_for_path:entry /usr/share/applications
I did notice that one time, I saw the events out of order (different
CPUs) and the icon didn't appear in the menu (CREATED,
ATTRIBUTED_CHANGED, CHANGED) instead of (ATTRIBUTE_CHANGED, CHANGED,
CREATED). However, I was never able to reproduce it with this single
file package.
Now contrast this with installing SUNWgftp:
1 62257 default_event_converter:return
G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED
1 62256 g_file_new_for_path:entry /usr/share/applications
...and uninstalling SUNWgftp:
1 62257 default_event_converter:return
G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED
1 62256 g_file_new_for_path:entry /usr/share/applications
1 62257 default_event_converter:return
G_FILE_MONITOR_EVENT_CHANGED
1 62256 g_file_new_for_path:entry /usr/share/applications
Looking at the manifests for both packages, there were only two
differences for the icon file itself: SUNWgftp specified restart_fmri,
while mine did not, and SUNWgftp.desktop file was slightly bigger than mine.
Going further, I discovered that if I installed SUNWgftp first, and then
my package with a single file (desktop file), then events for
SUNWgftp.desktop and my desktop file would show up.
In talking with Danek, he theorised that too many file events were
happening too quickly. So, I changed pkg(5)'s install() method to do a
time.sleep(1) which caused a one-second delay between each file install.
Once I did that, installing and uninstalling SUNWgftp consistently
showed events for the SUNWgftp.desktop file.
I don't know how gamin or gnome-panel handles file updates, but it
sounds like fen isn't being used right here.
Nicolas Williams mentioned the following that might be helpful:
"The application is expected to scan a directory that's changed, for
example.
So wait for event, scan, wait for event; in between there could have
been 10K events.
If the events simply piled up the application might never make progress,
or if there was a queue size limit and no drops the sources of the
events would have to be throttled.
To avoid losing events the app should stat the directory after
associating the dir and before blocking in port_get().
And it should check the mtime/ctime to see that it's not later than when
the app finished scanning the dir in response to the earlier event."
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
