Created attachment 175787 [details] Deleted files seem to have stored locations Deleted files apparently have their positions stored, as you can test by Shift+Del a file, then move another file with the same name from somewhere else into the Desktop by moving into the Desktop folder, instead of drag and dropping on the area.
According to comments on Bug 495990 , this is not supposed to happen.
I cannot reproduce this on git master, and I suspect all along it was a bug that's been fixed with the big refactor that's due to land in Plasma 6.3.0. ...Which is good, because if it *didn't* behave this way with the current architecture, it would signify that positions of deleted items were not removed from the config file, which would cause it to grow infinitely in size! The only way I can imagine for this to work without running into that problem would be to write the icon's position on the desktop into an extended attribute in the file itself. That way, if you made a copy and moved it elsewhere, deleted the version on the desktop, and moved the copy back to the desktop, the copy would know what position to appear at. There's precedent for this with Dolphin recently starting to write folder metadata into the folders themselves, so it doesn't need to leave hidden .desktop files all over the place. However I'm not sure it would be a good idea to do here; Plasma would have to open every file and folder on the desktop in order to get the positions, which could potentially be very slow and delay startup. With our current approach, the positions are looked up in a config file, which is very fast. As such, I don't think it's feasible to do this, sorry. Let me know if you disagree with my assessment, Akseli.
> As such, I don't think it's feasible to do this, sorry. Let me know if you disagree with my assessment, Akseli. I agree with you. If we kept the positions of deleted files, this would also mean that if you make a new file that happens to have same name, it would go into that place, despite it being completely new file. It's also far more reliable to keep the positions always up-to-date, so when removing a file from desktop it should be synced to the positioner. Our current positioner system is now *predictable* (with some caveats and edge cases as always). It being unpredictable was the big problem that caused all sorts of weirdness. Not removing file positions on file deletion would add to that unpredictability. Meanwhile I can understand wanting the files to return back to their place after restoring, in the current form of our desktop icon positioner it's not very feasible. Like I said in the other bug, it could be doable, but I believe it would cause more issues in the end. However it's worth to look into if/when this whole system is rewritten. :) But as of current situation, I am gonna have to say no, sorry.