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
