GNOME Bugzilla – Bug 330298
Desktop icons get shifted after relogin
Last modified: 2012-10-02 02:37:14 UTC
Please describe the problem: See the attached screenshots. I have installed GNOME 2.13 from the official GNOME/SVN overlay on a fresh install of Gentoo Linux (~x86). Steps to reproduce: 1. Install GNOME 2.13. 2. Log into the desktop for the first time. 3. Icons are correctly aligned (see screenshot #1). 4. Log out. 5. Log in again. 6. Icons are no longer correctly aligned (see screenshot #2). 7. Re-aligning the icons does not help, as they are again like in 6. after subsequent logins. Actual results: Icons are not correctly aligned (see screenshot #2) after the second login. Expected results: I expect the icons to be positioned at the same place they were when I logged out. Does this happen every time? Yes. Other information:
Created attachment 58876 [details] GNOME 2.13 desktop on first login. The icons are correctly aligned.
Created attachment 58877 [details] GNOME 2.13 desktop after second login. The icons are no longer correctly aligned.
I can confirm this one with garnome release 2.13.90 on Slackware 10.1
COnfirming. this seems to be the home folder moving down in the default desktop icon configuration. but sometimes it is the computer icon, depending on the icon placements.
Still seeing this with nautilus 2.13.91.
Ubuntu has some similar bugs: * https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/31236 "Activate showing the home folder, the trash, the computer icon and a few others (such as network mounts, which are treated as volumes). Position them in a clean way on your desktop. Logout and login again. The icons' positions will be reset." * https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/31881 "See attached image. This is how it always looks for me at each login, which means I have to invoke "Clean Up By Name" and that gets pretty annoying after a while. Not to mention the bad impression it gives. ...... http://librarian.launchpad.net/1576572/no_clean_up.png This is how it looks right after load, and right after Clean Up By Name. As you can see, "cartman" is below "Books" at login."
Easy way to get the issue: * clean up by name * press ctrl-R What is weird is that happens with a fr_FR.UTF-8 locale but non a C one on my dapper installation
https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/33814 is about that too, that's a frequent user complain, pressing ctrl-R is enough to get your desktop mixed ...
Created attachment 61525 [details] [review] nautilus-155337-icon-positioning-on-reload.diff This makes Nautilus not reposition the icons when they get reloaded. However, sometimes I still get overlapping icons when I insert a CD. The icon layout code is an old mess of badly-understood gunk. I'll just rewrite it with a more robust algorithm.
> This makes Nautilus not reposition the icons when they get reloaded. Federico: The patch that was committed two days ago should fix that issue as well, right? > However, sometimes I still get overlapping icons when I insert a CD. This may be the case when it gets added to the rightmost column. IIRC the code checks whether the x position of an icon is too far on the right to show it completely, and will just accept the position, where it should in fact still scan whether there is a free y position that is partly outside of the screen.
Just tested with Nautilus 2.14.1 and the issue seems to be solved.
Okay, I finally found the reason for this bug. finish_adding_new_icons() was ignoring all the icons with has_lazy_position turned on when filling up the placement grid, so the overlaps actually occurred on top of those icons. Also, we weren't saving the new position metadata (i.e. emitting the icon_position_changed signal) when an icon was thus repositioned.
Created attachment 66556 [details] [review] Patch from the Novell package
Here's an easy way to reproduce the remaining bug. 1. Insert a CD. You'll get a volume icon. 2. On the top-left corner of the desktop, arrange your icons like this: [ ] [ ] [ ] [ ] CD Home [ ] [ ] file.txt 3. Eject the CD. The CD icon will disappear. Now, move the Home icon to the left: [ ] [ ] Home [ ] [ ] file.txt 4. Insert the same CD again. You'll get an overlap: [[]] [[]] CDHome [ ] [ ] file.txt Manny's patch from comment #10 has the right analysis (lazy positions must not be taken into account when reloading), but the check is not done in the right place. The patch moves this check to nautilus-icon-container itself. Also, this makes icon_set_position() more consistent with lazy positioning. With the patch, once an icon goes through icon_set_position(), it no longer has a lazy position (because it has been "well-placed" already). The code in finish_adding_new_icons() now takes this into account. With this patch, I no longer get the bug where reloading the desktop causes the icons to move. Also, I cannot reproduce the bug of overlapping icons with the steps outlined above. I think this makes icon positioning completely correct.
Created attachment 75780 [details] [review] nautilus-330298-desktop-icon-overlap.diff This applies to Nautilus 2.16 and fixes icon overlaps and repositionings.
Committed to HEAD. This will appear in Nautilus 2.16.2. 2006-11-06 Federico Mena Quintero <federico@novell.com> http://bugzilla.gnome.org/show_bug.cgi?id=330298 Fix the use of lazy positioning, and the saving of metadata for lazily-positioned icons. Fixes https://bugzilla.novell.com/show_bug.cgi?id=155337 and https://bugzilla.novell.com/show_bug.cgi?id=174766. * src/file-manager/fm-icon-view.c (file_has_lazy_position): Only desktop icon files (not "real" files) have lazy positions. Don't consider whether the directory is loading; this is not the right place to check that. (fm_icon_view_begin_loading): Tell the icon container that we just started reloading. (fm_icon_view_end_loading): Tell the icon container that we finished loading. * libnautilus-private/nautilus-icon-private.h (NautilusIconContainerDetails): New flag "is_reloading". * libnautilus-private/nautilus-icon-container.h: New prototype for nautilus_icon_container_set_is_reloading(). * libnautilus-private/nautilus-icon-container.c (nautilus_icon_container_set_is_reloading): New function; sets an is_reloading flag in the icon container. (icon_set_position): Clear icon->has_lazy_position, since the icon will be well-positioned once this function exits. (finish_adding_new_icons): Do not ignore already-placed lazy position icons when filling the placement grid! Save the value of icon->has_lazy_position before calling assign_icon_position(). Since that function may call icon_set_position() (which will clear the flag), we need to keep the original value of the flag. (finish_adding_new_icons): Don't clear icon->has_lazy_position here; let icon_set_position() do it. (finish_adding_new_icons): Emit the icon_position_changed signal so that the parent knows that we moved an icon under it. This has the effect of updating/preserving the position metadata for has_lazy_position icons.
This patch breaks displaying of home/trash/computer icons in nautilus 2.16.2 - every single nautilus restart causes random icons re-positioning on my desktop. I've tested patch from #15 with 2.16.1 and it was working perfectly until upgrade to 2.16.2
(In reply to comment #17) > This patch breaks displaying of home/trash/computer icons in nautilus 2.16.2 - > every single nautilus restart causes random icons re-positioning on my desktop. > > I've tested patch from #15 with 2.16.1 and it was working perfectly until > upgrade to 2.16.2 > Same here, with 2.16.2 icons are repositioned every time I log in, confirmed on multiple installations.
Please reopen this one. I'm having the same problem here on gentoo with 2.16.2 nautilus. It's not such an important bug, of course, but it's really annoying Thanks
Bug 373895 has a patch attached for 2.16.2 attachment 76394 [details] [review] reopening since we have many complaints
Tried that and _seems_ to work fine Thanks
Same here. Also Nautilus also forget since 2.16.2 always to "toolbar-style".
i added a patch to fix bug 373895 and possibly this. Is just a revert half of changes that Federico made that works great.
You can also make the icons jump around by opening gconf-editor to /apps/nautilus/desktop and toggling the *_visible keys.
*** Bug 373895 has been marked as a duplicate of this bug. ***
I reverted federicos patch for now
For reference, this is the problem description in the mailing list: http://mail.gnome.org/archives/nautilus-list/2006-November/msg00018.html
Federico you might look at http://bugzilla.gnome.org/attachment.cgi?id=76588 it only reverts the critical part of your patch. We've been using this on Gentoo Linux with 2.16.2 and fixed this problem.
Other icon shuffling bug mentioned on launchpad: https://launchpad.net/ubuntu/+source/nautilus/+bug/84262 "Binary package hint: nautilus I noticed this (minor but annoying) bug after upgrading to feisty around herd2. I am using defaultish gnome desktop and the current version of nautilus is 2.17.90-0ubuntu1. Steps to reproduce: 1. Create a text-file to desktop (~/Desktop), for example foo.txt 2. Move the file's icon to somewhere else from its default place 3. Double-click the icon so it gets opened (in gedit here) 4. Write something and save 5. The icon is moved to upper left corner, while it should stay where it was (and did so in edgy). ..."
I just tried this on nautilus 2.7.90 on Gentoo. My results are this: Editing with gedit causes the icon to move. Editing with other programs (I tried abiword and gvim) does not.
(In reply to comment #30) > I just tried this on nautilus 2.7.90 on Gentoo. My results are this: > > Editing with gedit causes the icon to move. > Editing with other programs (I tried abiword and gvim) does not. That's probably because GEdit uses robust file saving (it first saves to a temporary file, then moves the original file to a backup, then moves the temp file to the original name). Nautilus probably detects that the original file got deleted in the second step and removes its metadata.
Or take a OGG-Vorbis Audio-File and some, let say, MP3-Files in a Folder. Sort them by "File-Typ" and click one time on the OGG-File, very very funny...
(In reply to comment #31) > That's probably because GEdit uses robust file saving (it first saves to a > temporary file, then moves the original file to a backup, then moves the temp > file to the original name). Nautilus probably detects that the original file > got deleted in the second step and removes its metadata. I think that a possible solution is to keep the metadata even for deleted files, by placing the pointers of the metadata entries into a "to-be-deleted" queue that gest emptied at the end of the session (or after a timeout of, say, five minutes if we want to be really paranoid about memory/disk usage). if a file is created and would have the same metadata of the deleted file (md5sum of the URI?), the metadata is removed from the "to-be-deleted" queue.
the nautilus monitoring code in nautilus-monitor.c checks for _CREATE and _REMOVE events on a folder. an atomic save as done by g_file_set_contents(), and the equivalent code inside gedit, is a "dump contents into a temporary file and then move it to the target path". if a file exists, then the move operation is an unlink+create - hence the REMOVE followed by a CREATE. when on the desktop - which is the interesting case - when we receive a REMOVE event we could push the metadata removal operation into an hash table, using the URI as the key and start a timeout (with a 30 seconds delay, to allow for slow I/O operations); when we receive a CREATE event, we check if the hash table contains the URI of the file and we remove the entry from the hash table if the lookup was successful.
*** Bug 451255 has been marked as a duplicate of this bug. ***
Alex, you said youreverted Frederico's patch but it is still marked as committed. Also, why don't we use Frederico's patch and omit the one line as suggested by Luis Medinas?
*** Bug 431824 has been marked as a duplicate of this bug. ***
*** Bug 374499 has been marked as a duplicate of this bug. ***
*** Bug 324368 has been marked as a duplicate of this bug. ***
Created attachment 93456 [details] [review] nautilus-330298-297983-fix-overlapping-desktop-icons.diff Another cut at the patch.
Comment on attachment 93456 [details] [review] nautilus-330298-297983-fix-overlapping-desktop-icons.diff I just gave it a quick whirl and noticed one thing: If I repeatedly connect and disconnect the same drive (be it an USB stick or a DVD) it will always assign a new place on the desktop to it (the next free spot after the one it occupied before, as if that one was marked to be taken).
(In reply to comment #40) > Created an attachment (id=93456) [edit] > nautilus-330298-297983-fix-overlapping-desktop-icons.diff > > Another cut at the patch. > even applying your patch, when a user has already logged in and mounted a DVD, if I login in other screen, DVD icon is not placed properly
Created attachment 104065 [details] 1.png Screenshot showing the problem
I think I finally fixed all kinds of overlapping desktop icons with a massive patch, introducing a concept of layout timestamps: http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14519 Please give it some testing before GNOME 2.14. Closing.
I think I finally fixed all kinds of overlapping desktop icons with a massive patch, introducing a concept of layout timestamps: http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14519 Please give it some testing before GNOME 2.24. Closing.
*** Bug 338201 has been marked as a duplicate of this bug. ***
This bug possibly needs to be re-opened, as reports are coming of the same issue in 2.28. https://bugs.launchpad.net/nautilus/+bug/36244/comments/15 I confirm the same issue on my desktop: position of icons of symlinks placed on my Desktop gets reset to stick to the grid after relogin. It seems that it might be related to Bug 589516 .
Confirming, I can reproduce. -> "Symlink icons get shifted on re-login" Devs, should we reopen or file a separate bug?
Sorry, typo above in comment 47. The bug which may be related is Bug 589156.
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.
*** Bug 333358 has been marked as a duplicate of this bug. ***