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 402621 - gnome-control-center wipes out /home/user
gnome-control-center wipes out /home/user
Status: RESOLVED FIXED
Product: gnome-main-menu
Classification: Other
Component: libslab
unspecified
Other Linux
: Normal blocker
: ---
Assigned To: Scott Reeves
GNOME main menu maintainers
Depends on:
Blocks:
 
 
Reported: 2007-01-30 21:57 UTC by Sebastien Bacher
Modified: 2007-03-22 19:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to fix the problem (3.57 KB, patch)
2007-01-30 22:07 UTC, Sebastien Bacher
none Details | Review
patch update to fix the bug (4.16 KB, patch)
2007-01-30 22:54 UTC, Sebastien Bacher
none Details | Review
patch update (4.16 KB, patch)
2007-01-31 13:45 UTC, Sebastien Bacher
none Details | Review
updated patch (6.80 KB, patch)
2007-01-31 22:29 UTC, Scott Reeves
none Details | Review

Description Sebastien Bacher 2007-01-30 21:57:45 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
Comment 1 Sebastien Bacher 2007-01-30 22:07:37 UTC
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?
Comment 2 Sebastien Bacher 2007-01-30 22:54:05 UTC
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
Comment 3 Scott Reeves 2007-01-31 01:22:44 UTC
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.
Comment 4 Rodrigo Moya 2007-01-31 11:23:36 UTC
> 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?
Comment 5 Sebastien Bacher 2007-01-31 13:45:14 UTC
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
Comment 6 Scott Reeves 2007-01-31 22:29:56 UTC
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?
Comment 7 faplap 2007-03-21 22:46:33 UTC
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...
Comment 8 Jim Krehl 2007-03-22 19:44:11 UTC
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.