Created attachment 150484 [details] wrong file path after drag+drop image while pressing ctrl+shift, and correct one (image->insert) Problem description: whenever I insert an image by dragging and dropping while pressing ctrl+shift keys, it results in a linked image, but with a wrong path (see attached file, 1st picture): you can spot the wrong path file, because the filename got changed with random character and usually is present the tilde operator; this behavior doesn't apply only the filename part of the path, but I've seen also happen to parts of the root. The correct pathfile, shown in the 2nd figure of the attached file, is obtained by linking the image via the menu (insert -> image -> select picture -> check link box -> OK) The image linked with the drag+drop/ctrl+shift method is correctly displayed if the file is accessed on the original machine, but fails to resolve the path if the document is accessed by another machine ------------------------ Step to reproduce: 1. Open a document in LO writer 2. Drag and Drop a file in the document while pressing ctrl+shift 3. Double click on the inserted image and check filename on the image tab ------------------------ Current behavior: the filepath doesn't match the real path where the file is saved; accessing the LO document from any other machine could not resolve the path and image is not displayed ------------------------ Expected behavior: the filepath match the real path where the file is saved; accessing the LO document from any other machine shows the image as expected
Reproducible with Version: 6.2.3.1 (x64) Build ID: 9ba025bafb03b962c34687cf87806cc03a3a7436 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL The problem is that Windows passes short file name in its IDataObject passed to drag-and-drop target (like C:\Pictures\2E23~1.PNG). This is extracted in SwTransferable::PasteGrf, and converted to URI like file:///C:/Pictures/2E23~1.PNG; given that the autogenerated short name might differ on the other system where the document and the linked file are copied, using the short name from original system to load the link could fail. We need to add a call to GetFullPathNameW somewhere in the call chain to convert to full filename. Also reproducible with OpenOffice.org 3.2.0 OOO320m12 (Build:9483).
https://gerrit.libreoffice.org/70145
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b81ea32945d553a712d651fe472ece921ac64d10%5E%21 tdf#124500: convert short path names from drag-n-drop to long names It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.