Comment 9 for bug 403130

Revision history for this message
William Anderson (william-anderson) wrote :

my icon reset experience

This issue occurred on my laptop. I think that this is caused by either a corrupt configuration file or by a version upgrade that does not handle the old versions configuration correctly. At this time i think that the former condition is the cause.

I upgraded to Ubuntu 9.10 on 13 November from version 9.4. According to Synaptic, the version of Nautilus installed is 1:2.28.1-0ubuntu3 and the version of Gnome is 1:2.29.0-0ubuntu1 .

This issue started for me sometime in mid November. This was after the upgrade to 9.10, and the system worked without a problem right after the upgrade. The upgrade did not cause this problem.

What I think caused the problem was my filling up my home file system. Shortly after this (on the first reboot, which was a couple of days later) this issue appeared. I ignored the problem for a while as I only log out when I reboot or more frequently, kill the battery on the laptop. Today I decided to find and fix this problem.

After searching the web i found several bugs at both the Ubuntu and the Gnome bug sites with issues that seem related to my problem.

(Desktop icons get shifted after relogin at https://bugzilla.gnome.org/show_bug.cgi?id=330298)
('Keep Aligned' option always resets to 'true' after desktop reload at
https://bugzilla.gnome.org/show_bug.cgi?id=589156)
(Desktop icon placement reset at login at https://bugs.launchpad.net/nautilus/+bug/36244)
('Keep Aligned' option always resets to 'true' after desktop reload at https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/399974 )
(All my desktop icons were rearranged at https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/403130)

The older reports (from 2006 to 2007) are all closed as resolved and fixed two or four minor versions before the version that i have installed. Could this be a regression test failure and the reappearance of an old bug. Possibly.

On one of the newer bug reports, from July 2009, indicated that the problem occurred in one user account but not in another. To test this, I created a second user account on my laptop. When logging in, creating a group of empty files and directories and moving them around, then logging out and back in, I found that the custom positioned files remained in the same location that they were placed. This means that the problem is in the configuration files of the user that the problem occurs with and not a global software issue.

I then made a list of the configuration files that were created when that new user was created and logged on. I made a tar archive of those files for reference. I also made a backup tar archive of all of the configuration dot files and directories in my home directory. I then deleted the configuration files that were created for the new user. (All of this was done not logged into a gnome session and logged in to a terminal console session.) The list of files deleted at this time is .config/ .gconf/ .gconfd/ .gnome2/ .gnome2_private/ .gvfs/ .nautilus/ . Logging into gnome I found that all customized settings were reset (background image, home as desktop, window themes, etc), as expected. I then moved a file or two, logged out then back in. This resulted in all of the files being sorted back to where the desktop wanted them.

I then again removed the first seven configuration directories and removed these directories, too: .cache .checkbox/ .compiz/ .dbus/ .debtags/ . This netted me the same result.

Next I deleted the symlink called Desktop that was pointing at my home directory to satisfy some applications that insists on saving to the path /home/william/Desktop regardless of the gnome/nautilus desktop setting (Firefox). I let this directory get recreated during login, restoring my configuration to what should be a truly vanilla state. I got the same result.

Next, I deleted all of the above files (at least those that were recreated) and also deleted the following dot files and directories: .egl-0.0/, .gksu.lock, .h2h/, .ICEauthority, .icons/, kde/, .local/, .orca/, .qt/, .pulse, .pulse-cookie, .seq24rc, .spumux/, .themes/, .tovid/, .update-manager-core/, .update-notifier/, .wapi/, .winff/, .xine/, .xmame/ . I did the log on, move files, log out, log back on test, and found that the file icons that i moved stayed moved.

One of these files or directories contains the source of the problem. To isolate exactly what is happening, I started copying files back one at a time to make the problem appear again.

.tovid/, .xine/, .xmame, .seq24rc, .spumux/, .qt/, .orca/, .debtags/ .wapi/, .winff/, ./fr-BBBB, .h2h/, .compiz/, .egl-0.0/, .ICEauthority, .update-manager-core/, .update-notifier/, .checkbox/, kde/

All of these files do not cause any trouble. At this point, I am left with configuration directories and files that have been recreated. I will start replacing these one at a time:

.pulse, .pulse-cookie, .themes, .icons/

The directories/files above have no effect, The problem remains gone. Last but not least of the configuration dot files, .local, causes the icons to rearrange when the old one is put in place. Putting the new copy back and all of the desktop returns to the sorted state. Is this where the desktop icon location information is stored?

Within this directory (the new one) is the subdirectory share. Under that is the directory gvfs-metadata. Under that is a selection of binary files. In the newly created directory, these files come in pairs, a "data" file and a "log" file, both of which are binary files. there is a computer, a home, a cd-rom, and a root pair of files. In the new directory, all of these files have some size. In the corrupt directory, several of these are zero bytes in size, including the "home" file.

Likely what is happening is that these files are where the icon positions are stored. When I ran out of disk space, whatever system (gvfs?) that uses these files was unable to write updates, and left the file zero bytes in size. When restarting or rereading, the system finds a zero byte file and is then somehow unable to either modify the file or create a new file. It then falls back to a default desktop icon sorting scheme.

This is a bug with whatever system uses this, and while the broken system defaults to something that makes the computer usable, it should also be able to recreate the damaged files if needed and fix this kind of problem.

To force this behavior to happen, log out of the gnome session, log in to a command line terminal, change to the directory ~/.local/share/gvfs-metadata, move the file home to home.bak, touch the file home (create a zero byte file), log back into the gnome session. All of the desktop icons will be arranged by the default sorting scheme, and while you can move them around, when you log off and log back on you will find that all of the icons will have returned to that default sort location. Fix the problem by either replacing the zero byte file with the original (if you have it), or by deleting the zero byte file. After deleting the zero byte file, icon position changes will be saved as the system does know enough to create the missing files.

This is not a bug in Nautilus, beyond that the system used by Nautilus to store desktop icon location information gets corrupted and reverts to a default behavior. It has nothing what so ever to do with the "Keep Aligned" option in the desktop pop up menu, nor the issue that that option does not seem to ever be unselectable on all of my systems.

Hopefully, this helps