Description: Any LibreOffice document opened from its icon on my desktop, then edited and saved will be saved to the first available spot on the desktop instead of the spot where from it was originally opened. Steps to Reproduce: 1. Open document from anywhere on the desktop and edit. 2. Save edit and close LibreOffice. (observe that document has been saved to first available space a left of desktop and the original icon is now gone) Actual Results: Document icon moves from original location to first available spot on desktop Expected Results: The document should have been saved to its original location on the desktop. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.1.0.3 Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 2; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group threaded
Not reproduced. Document stays put. I first moved it to an original spot, so I could guarantee optimal conditions to see the bug. Version: 6.1.0.3 (x64) Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: fi-FI (fi_FI); Calc: group threaded
Do other programs behave correctly? You don't have some automatic sorting enabled for the desktop?
Ah, Mike Kaganski commented on IRC: "This is because we create a new file which then gets renamed (we don't write into the same file), so Explorer decides itself if it needs to re-arrange things" Closing as notabug
jmux mentioned https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-replacefilew which we could try for replacing the old file with new file. Let's set it to new (I do reproduce this), in case someone wants to try this approach.
Steps to reproduce: 0. Ensure you *don't* have auto-sorting for desktop icons. 1. Put a document to desktop, so that it is *not* in a "natural" place (i.e., not in a contiguous section of icons starting from top-left (in LTR) corner of screen - put it so it is surrounded by free space from all sides). 2. Open if in LO and save it. Due to the old file being deleted, and a new file created and renamed to the old name, the new file will be handled as a different entry by Explorer (the process showing desktop); it will put the new file to the "natural" place.
Sigh... from "NOTABUG" to "ASSIGNED to myself"... I must look inconsistent ;-) https://gerrit.libreoffice.org/60163
https://ask.libreoffice.org/en/question/166460/why-are-my-desktop-icons-changing-position/ suggests that it's a regression... could it be bibisected?
Regression introduced by https://cgit.freedesktop.org/libreoffice/core/commit/?id=2157a3536f97ff5ae7c82611a801fef7e3708983 author Miklos Vajna <vmiklos@collabora.co.uk> 2018-01-08 16:49:25 +0100 committer Miklos Vajna <vmiklos@collabora.co.uk> 2018-01-09 09:09:27 +0100 sfx2 store: try rename before copying Rename is cheaper then copying the content over manually, so try that first. This also changes the document's *creation* time.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c9343988204ee3e9889f3cc833adbbaca83e53e6 tdf#119238: keep replaced file's identity when renaming docfile It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4f28521bf96d4a5fedad3c85171baba412abbb0e&h=libreoffice-6-1 tdf#119238: keep replaced file's identity when renaming docfile It will be available in 6.1.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 120328 has been marked as a duplicate of this bug. ***