Download it now!
Bug 119238 - Documents opened from desktop are not later saved to the same spot on desktop
Summary: Documents opened from desktop are not later saved to the same spot on desktop
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All Windows (All)
: medium minor
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.2.0 target:6.1.3
Keywords: bibisected, bisected, regression
: 120328 (view as bug list)
Depends on:
Blocks: Desktop-Integration rename-before-copy-regressions
  Show dependency treegraph
 
Reported: 2018-08-13 00:38 UTC by damonelewis
Modified: 2019-07-03 14:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description damonelewis 2018-08-13 00:38:42 UTC
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
Comment 1 Buovjaga 2018-09-07 13:14:24 UTC
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
Comment 2 Buovjaga 2018-09-07 13:15:38 UTC
Do other programs behave correctly?
You don't have some automatic sorting enabled for the desktop?
Comment 3 Buovjaga 2018-09-07 13:22:50 UTC
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
Comment 4 Mike Kaganski 2018-09-07 13:34:33 UTC
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.
Comment 5 Mike Kaganski 2018-09-07 13:43:05 UTC
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.
Comment 6 Mike Kaganski 2018-09-07 14:19:37 UTC
Sigh... from "NOTABUG" to "ASSIGNED to myself"... I must look inconsistent ;-)

https://gerrit.libreoffice.org/60163
Comment 7 Mike Kaganski 2018-09-22 20:25:41 UTC
https://ask.libreoffice.org/en/question/166460/why-are-my-desktop-icons-changing-position/ suggests that it's a regression... could it be bibisected?
Comment 8 Mike Kaganski 2018-09-23 06:28:21 UTC
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.
Comment 9 Commit Notification 2018-09-27 14:44:24 UTC
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.
Comment 10 Commit Notification 2018-09-27 21:20:58 UTC
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.
Comment 11 Mike Kaganski 2018-10-07 07:35:52 UTC
*** Bug 120328 has been marked as a duplicate of this bug. ***