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 45953 - Need to delete position metadata for rm-ed files
Need to delete position metadata for rm-ed files
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Desktop
2.11.x
Other All
: High normal
: ---
Assigned To: Federico Mena Quintero
Nautilus Maintainers
DRIZZT[device]
: 76337 130407 142435 143853 303689 308641 311041 319256 (view as bug list)
Depends on:
Blocks: 95648
 
 
Reported: 2001-01-23 11:57 UTC by Taylor Richards
Modified: 2009-11-07 17:58 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
This is an image of poor icon placement in action. (67.08 KB, image/png)
2004-09-05 02:57 UTC, dowem
  Details
Proposed patch (6.82 KB, patch)
2005-08-14 22:54 UTC, Christian Neumair
committed Details | Review
gnome-vfs2-115467-remove-deleted-file-metadata.diff (940 bytes, patch)
2005-11-04 02:21 UTC, Federico Mena Quintero
committed Details | Review
nautilus-45953-dont-overlap-volume-icons.diff (1.24 KB, patch)
2005-11-08 01:09 UTC, Federico Mena Quintero
committed Details | Review
Patch to handle external removes (732 bytes, patch)
2006-12-07 07:28 UTC, Gene Z. Ragan
none Details | Review

Description Taylor Richards 2001-09-10 01:00:53 UTC
Icons from mounted devices tend to overlap each other.  They also do not display
in a particular order, eg. first mounted icon/drive shows below second mounted
icon/drive.

Partial screenshot available from link (JPEG: 8.7K)


(nightly build: 200101220919)



------- Additional Comments From don@eazel.com 2001-01-23 09:31:10 ----

Gene ...




------- Additional Comments From gzr@eazel.com 2001-01-24 09:09:42 ----

It appearts that the remounted volume icon is using it saved location 
information to reposition itself.  I will do some research to see what other 
alternatives we have if there is an overlap.



------- Additional Comments From gzr@eazel.com 2001-02-01 16:45:31 ----

There are three possibilites here:

1. Leave behavior the way it is
2. Purge icon position when unmounting
3. Detect and correct icon collison when mounting

Choice three is the best, but borders on a new feature.



------- Additional Comments From eli@eazel.com 2001-02-09 11:28:36 ----

Duane is now the proud owner for Desktop QA.



------- Additional Comments From eli@eazel.com 2001-03-26 11:19:53 ----

SPAAAAAAAAAM! 

(Jon Allen has taken these components; QA Assigning bugs to him.)



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 21:00 -------
Comment 1 John Fleck 2002-01-05 04:16:46 UTC
Changing to "old" target milestone for all bugs laying around with no milestone set.
Comment 2 Tuomas Kuosmanen 2002-05-31 17:13:22 UTC
Just thinking we could do something simple about this, so here is a
suggestion:

* Put all mounts to top right corner of the desktop.
* Put trash on bottom right (of course remember position if one 
  moves it)
* Default launchers and other stuff to topleft corner of the screen

This way, it would be at least a bit more clean organization. I dont
think we need any preferences for this, though I can hear some freaked
out screaming about how someone wants to control where stuff goes :-)
But something like this as the default behaviour would definitely
clear things up and make things more simple. The "oh, where is the
device I mounted..? doh, under the Home icon!" -stuff is just confusing.
Comment 3 Dave Bordoley [Not Reading Bug Mail] 2002-05-31 17:15:53 UTC
I think the behavior tigert describes here should be the default
cleanup behavior on the desktop :)
Comment 4 Dave Bordoley [Not Reading Bug Mail] 2002-05-31 17:22:03 UTC
changing to future, adding gnome2 and usability keywords.

Also it would be nice if the desktop used seperate metadata for icon
position and icon stretching. That way you could use manual layout for
the desktop directory in the file manager without having icons that
are stretched on the desktop stretched in the icon view, or have icons
places all wierd. I have another bug for this open, but just thought
i'd mention it here too.
Comment 5 Dave Bordoley [Not Reading Bug Mail] 2002-05-31 17:22:43 UTC
*** Bug 76337 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Munck Steenholdt 2002-07-17 13:25:40 UTC
Would it be possible even, to make an option to lock a device icon on
the desktop(even when not mounted) sort of what is possible in KDE and
the only way in Windoze... Then only the title and possible the icon
for the device should be changed on mount.
This would make it real easy to arrange devices so that you CD-ROM is
always icon number three from top right and the CD-RW is right below
that on, etc... Hope you get my point... Even automounting of a device
when double-clicking the icon would be great!
Comment 7 Elijah Newren 2003-01-13 20:55:19 UTC
I tend to miss dependencies and blocks, so I'll add a comment here to
look at bug 95648 (which is about the cd-rom icon forgetting its
position).

This bug, in combo with bug 95648, seems like a "cosmetic bug of
particularly high visibility", so I'm setting priority to high.

Now, in regards to tigerts suggestions:

It may be important to note that having icons near corners other than
the top left is potentially problematic when the screen resolution is
changed (see bug 47943).  I don't know how difficult this may be to
fix (bug 41670, which is nearly identical to tigert's suggestion,
claimed this problem was already fixed--though if it was, it has since
been broken again).  A possible solution to this may be using negative
locations (again, I've talked about this more in 47943).

Note that I believe the snap-to-grid feature that I'm trying to write
(see bug 41671 and note my disclaimers) should naturally allow for
icons in the top-right and bottom-right corners (bottom-left corner
may be problematic, unless, perhaps, I can come up with some
workaround--such as the one I can think of if negative locations were
used to keep track of icons near corners other than the top left)).
Comment 8 Matthew Gatto 2004-01-24 21:43:38 UTC
*** Bug 130407 has been marked as a duplicate of this bug. ***
Comment 9 Matthew Gatto 2004-01-24 21:46:25 UTC
Changing the Severity from enhancement -> normal, since it seems like
a flat out bug.
Comment 10 Martin Wehner 2004-05-14 00:48:33 UTC
*** Bug 142435 has been marked as a duplicate of this bug. ***
Comment 11 dowem 2004-09-05 02:51:50 UTC
This still happens with 2.7.92, Now that the new hotness g-v-m is upon us, and
automagical mounting of devices is becomming commonplace, this should seriously
be looked at for the next release (2.9). I will add a new screenshot
illustrating the behaviour. 
Comment 12 dowem 2004-09-05 02:57:29 UTC
Created attachment 31279 [details]
This is an image of poor icon placement in action. 

This is a screenshot of the placement of the cdrom icon after mnounting
automatically. (If it is of any relevance, "keep aligned" is set for my
desktop.
Comment 13 Sebastien Bacher 2005-02-02 10:05:10 UTC
still here with 2.9.90, that would be nice to get that fixed for 2.10 if
possible ...
Comment 14 Sebastien Bacher 2005-02-02 10:07:20 UTC
*** Bug 143853 has been marked as a duplicate of this bug. ***
Comment 15 sdiconov 2005-02-02 12:50:49 UTC
Can the device icons be turned off altogether as an option? 

I run submount and they become really nasty. The icons always stick on the
desktop and have no useful functions. And they confuse fresh ex-windows users.  
Comment 16 Martin Wehner 2005-05-10 18:51:26 UTC
*** Bug 303689 has been marked as a duplicate of this bug. ***
Comment 17 Malte 2005-05-23 17:21:03 UTC
@sdiconov: You're probably interested in the gconf key
/apps/nautilus/desktop/volumes_visible.
Comment 18 Mace Moneta 2005-05-23 17:37:24 UTC
Is it really that hard to programatically call 'clean up by name' when
displaying a new desktop icon, that it's taking 4 years to correct?
Comment 19 Christian Neumair 2005-05-23 18:39:55 UTC
Mace: By auto-cleaning up by name, you'd seriously break users' layout. I rather
suppose we ensure that the old icon position metadata for the newly mounted
device is ignored and instead a new empty position determined if the old
position overlaps with another icon on the desktop.
Comment 20 Christian Neumair 2005-05-23 19:05:37 UTC
The relevant layout code is in reload_icon_positions. If we are on the desktop
and have_stored_position is TRUE, we may only want to restore the metadata
position it if it doesn't interfere with another (already displayed) item. This
could be done by calling nautilus_icon_container_get_is_desktop and
eel_canvas_get_item_at for the upper and lower icon boundary coordinates. The
trick is probably that this should only be done for volumes. I suppose it would
be ugly, but we could get the metadata name and check whether it ends in
".volume" - or we'd have to ask FMIconView whether a particular NautilusIcon has
a volume associated with it, maybe by changing the NautilusIconContainer API and
adding a NautilusIconIsVolume callback or something.
Comment 21 Sebastien Bacher 2005-06-24 11:52:19 UTC
*** Bug 308641 has been marked as a duplicate of this bug. ***
Comment 22 Teppo Turtiainen 2005-07-20 19:05:40 UTC
*** Bug 311041 has been marked as a duplicate of this bug. ***
Comment 23 Josh Lee 2005-07-24 21:59:33 UTC
You can also make this bug show up by going into a terminal and typing:

 touch hello1
 rm hello1
 touch hello2
 touch hello1

So it's not just limited to volumes. Basically, when restoring a desktop icon
that has a remembered size/position, check for conflicts and throw away the
remembered position if there is a conflict.
Comment 24 Teppo Turtiainen 2005-07-25 03:59:43 UTC
Bumping up version to 2.11.x.
Comment 25 Ignas Mikalajunas 2005-08-03 14:11:29 UTC
I am not sure whether it is another bug or it is the result of this one.

When two icons overlap and are at the exactly same position (pixel to pixel) if
one navigates through desktop icons with keyboard and marks one of the
overlaping icons - there is no way you can unfocus them by using your keyboard.

Way to reporoduce:

Get two overlapping icons.
Select one of them (let's call it Icon1 and the overlaping icon - Icon2).
Click any arrow key.
Icon2 is selected.
Click any arrow key.
Icon1 is selected.
Click any arrow key.
Icon2 is selected.
...

No way to select another icon on your desktop without falling back to your mouse.
Comment 26 Christian Neumair 2005-08-14 22:54:05 UTC
Created attachment 50703 [details] [review]
Proposed patch

I've also submitted the patch to the nautilus mailing list [1] for review.

[1] http://mail.gnome.org/archives/nautilus-list/2005-August/msg00135.html
Comment 27 Christian Neumair 2005-08-14 22:56:15 UTC
Ignas: That's another issue. We probably shouldn't snap to grid when dropping
where another icon is already located.
Comment 28 Alexander Larsson 2005-09-19 10:10:32 UTC
I commited the patch, but there is still a problem on startup, and when files
get resurrected. 

See http://mail.gnome.org/archives/nautilus-list/2005-September/msg00147.html
for details.
Comment 29 Federico Mena Quintero 2005-11-04 00:14:47 UTC
Assigning to myself; I'm working on this.
Comment 30 Federico Mena Quintero 2005-11-04 02:20:11 UTC
This is actually three different bugs:

Bug 1:

  cd ~/Desktop
  touch foo       <- icon appears
  right-click on foo
  select "Delete" instead of "Move to trash" <- icon disappears
  touch bar       <- icon appears where foo used to be
  touch foo       <- icon appears, overlapping bar

Bug 2:

  cd ~/Desktop
  touch foo       <- icon appears
  rm foo          <- icon disappears
  touch bar       <- icon appears where foo used to be
  touch foo       <- icon appears, overlapping bar

Bug 3:

  the CD-ROM thing

I have a fix for (1); will attach it immediately.  I'm working on (2) and (3).
Comment 31 Federico Mena Quintero 2005-11-04 02:21:17 UTC
Created attachment 54302 [details] [review]
gnome-vfs2-115467-remove-deleted-file-metadata.diff

Patch for Bug (1) above.  This is actually a gnome-vfs problem.
Comment 32 Federico Mena Quintero 2005-11-08 01:09:36 UTC
Created attachment 54448 [details] [review]
nautilus-45953-dont-overlap-volume-icons.diff

Actually, the fix for case (3) above is quite simple.  Manny already had code
to distinguish icons which have a stored position, but which we don't want to
overlap.  I just changed the tests a bit so that even if an icon has a stored
position (like a volume icon), it will be put in the semi_position_icons list
to make sure that there are no overlaps.

This fixes the "volume icons overlap" bug for me, and it's the patch I'll use
for our Novell package.  I'm just missing case (2).
Comment 33 Alexander Larsson 2005-11-14 15:29:51 UTC
I commited both patches (with a coding style change).
Comment 34 Federico Mena Quintero 2005-11-14 18:45:59 UTC
Thanks, Alex :)

So, to summarize, the only thing that remains is case 2 from comment #30.  I'll
rename the bug to indicate this.

Any idea of how Nautilus finds out that a file disappeared on the outside?  I
set breakpoints in the obvious functions in nautilus-monitor, but they never
triggered...
Comment 35 Vincent Untz 2005-12-31 14:33:58 UTC
*** Bug 319256 has been marked as a duplicate of this bug. ***
Comment 36 Gene Z. Ragan 2006-12-07 05:41:13 UTC
The touch1/rm/touch2/touch1 flaw is still present in CVS HEAD.  I'll take a look at why.
Comment 37 Gene Z. Ragan 2006-12-07 07:14:31 UTC
nautilus-monitor is not removing the metadata in the case caused by rm or any other non-Nautilus driven action.

Patch submitted to the nautilus list.
Comment 38 Gene Z. Ragan 2006-12-07 07:28:01 UTC
Created attachment 77876 [details] [review]
Patch to handle external removes
Comment 39 Alexander Larsson 2006-12-08 09:23:31 UTC
Commited. 
Comment 40 Federico Mena Quintero 2006-12-10 18:01:04 UTC
Gene, you are my hero.  I couldn't find the right place to put that code.  Thanks for fixing this!
Comment 41 Cristian Aravena Romero 2008-03-21 17:38:51 UTC
Of:
https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/12454/comments/9

"I have encounter this problem again in Hardy Beta."

Bug:
https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/12454
Comment 42 Martin Ejdestig 2008-04-30 12:30:00 UTC
Confirming. Reopen or open a new bug?
Comment 43 Paweł Paprota 2008-05-02 08:17:29 UTC
There's already new report on the issue (bug 531019) so I guess we can use it instead of reopening this one.
Comment 44 Alessio Bolognino 2009-11-07 17:58:09 UTC
This bug:

  touch foo       <- icon appears
  rm foo          <- icon disappears
  touch bar       <- icon appears where foo used to be
  touch foo       <- icon appears, overlapping bar

is still here (2.28.1). It's super annoying.