GNOME Bugzilla – Bug 402621
gnome-control-center wipes out /home/user
Last modified: 2007-03-22 19:44:11 UTC
That bug has been opened on https://launchpad.net/ubuntu/+source/control-center/+bug/78500 "Binary package hint: gnome-control-center How to reproduce : start gnome-control-center, select (the old) disk-admin icon left behind from dapper, right click with mouse and select "remove starter" from the popup menu. As a result of this, you'll find you're /home/user directory wiped clean ! :-( I've just lost my whole setup and all my documents, just doing these simple steps, I'm lucky to own a recent disc-image of that partition. ;-) ... > The gconf key to get the value from is rather that one: /desktop/gnome/applications/main-menu/file-area/user_startup_dir ... Launching gconftool produces this output: No value set for /desktop/gnome/applications/main-menu/file-area/user_startup_dir ..." The problem is that the schemas for that key is shipped with gnome-main-menu and not gnome-control-center The code from application-tile.c does that then: " gconf_startupdir = get_slab_gconf_string (SLAB_USER_STARTUP_DIR_KEY); src_filename = g_build_filename (g_get_home_dir (), gconf_startupdir, ditem_basename, NULL); src_uri = gnome_vfs_uri_new (src_filename); list = g_list_append (list, src_uri); gnome_vfs_xfer_delete_list ( list, GNOME_VFS_XFER_ERROR_MODE_ABORT, GNOME_VFS_XFER_REMOVESOURCE, NULL, NULL); priv->startup_status = APP_NOT_IN_STARTUP_DIR;" When the gconf_startupdir has no value then list = USER_DIR which creates the bug described before
Created attachment 81551 [details] [review] patch to fix the problem That patch uses the glib functions to get the autostart directory instead of using a gconf key. Those locations are defined by a freedesktop specification, why do you need to overwrite them by a gconf key specific to the lib?
Created attachment 81555 [details] [review] patch update to fix the bug that new patch use g_unlink on a filename rather than gnome_vfs_xfer_delete_list
Thanks for the patch. Couple issues though 1. tacking basename on g_get_system_config_dirs()[0] does not point to the files in my global autostart dir. 2. We don't want to lose the priv->startup_status = APP_NOT_IN_STARTUP_DIR line in remove_from_startup_list 3. Since it's a file we want to remove maybe we ought to do a G_FILE_TEST_IS_REGULAR instead of G_FILE_TEST_EXISTS.
> 1. tacking basename on g_get_system_config_dirs()[0] does not point to the > files in my global autostart dir. > g_get_system_config_dirs uses XDG_CONFIG_DIRS variable AFAIK, what values do you have?
Created attachment 81589 [details] [review] patch update that patch doesn't drop the APP_NOT_IN_STARTUP_DIR, for the g_file_test is there any reason symlinks should not be accepted? the patch is probably fine either way. for the g_get_system_config_dirs() call, what directory do you get? that works fine on my Ubuntu desktop
Created attachment 81632 [details] [review] updated patch As discussed on control-center, the patch was updated to look in each returned directory appending “autostart” and “gnome/autostart”. Also remove gconf key from the schema. One strange thing is it appears gnome-session looks in XDG_DATA_DIRS so I changed to g_get_system_data_dirs. Look good?
I today built an SVN version of this (via http://svn.gnome.org/svn/gnome-main-menu/branches/version-2/) and unfortunately found this bug, to my great dismay, as noted above - open main menu, right click on a favorite application, hit 'Remove from Startup menu'. My home directory was fortunately only PARTIALLY wiped, but it only left stuff I didn't care about (no idea why it stopped halfway, presumably the offending process died in the course). So, I'm not sure this should be marked RESOLVED/FIXED...
This bug was fixed in the trunk. The "version-2" branch that you checked out did not have this fix. This branch was merged into the trunk on 2007-02-26 and is now obsolete.